From glen at glenjarvis.com  Sat Oct  2 18:44:05 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Sat, 2 Oct 2010 09:44:05 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
Message-ID: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>

I've now seen a common problem come up several times. And, I imagine there
is a common solution to this problem that I don't know.

About a year ago, I wrote an automatic script that would automatically do an
'svn export' of certain branches of a tree depending upon what menu option
the customer chose. When I did the svn export, I used subprocess.Popen.

The pattern was similar to the following:

print """This output is being buffered so I can read the version number.

    ....  I'm not stuck, just busy exporting files....

"""

.....

process = subprocess.Popen(['svn', 'export', repository,
repo_name], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
stdoutdata, stderrdata = process.communicate()


I printed "please wait" and then printed the data given when the process was
done (stdoutdata). It wasn't ideal but, it was sufficient for the time. If I
were to have gone for the best fix, I would probably have learned the API
for subversion to integrate directly into python.

However, another BayPIGgie is having the same issue. He is using a command
to start a CD burner from the command line and wants to print the output as
it is being created from the command line.

I can see that to solve this we wouldn't use the communicate() convenience
function. A few 'hackish' ways that may solve this, but I'm looking for the
common pattern that is used when other pythonista run up against this
problem. I also want to ensure that I don't have a 'hack' that causes a
deadlock only to discover this much later after I've implemented the pattern
a few times.

To help keep the conversation more focused, I've created two tiny test
programs for a test case:
1) A C command line program that we have no control over changing within
python, and
2) A Python program that calls that the c-program (baypiggies_demo):

Compile command line so output is same as expected by Python program:
gcc -pedantic baypiggies_demo.c -o baypiggies_demo


---- start of c program: File: baypiggies_demo.c ---
#include <stdio.h>
#include <unistd.h>

int
main()
{
    int             i = 0;

    printf("Silly output for monitoring...\n");
    for (i = 0; i <= 10; i++) {
        printf("Counting... %d\n", i);
        sleep(1);
    }
}
--- end of c program ---



--- start of python program to demonstrate. File baypiggies.py ---
import subprocess

print "Just waiting...."

process = subprocess.Popen(['./baypiggies_demo'],
                    stdout=subprocess.PIPE)

stdoutdata, stderrdata = process.communicate()

print "Well, NOW I get it.. :( "
print stdoutdata
--- end baypiggies.py --



Has anyone else ran into this before? What's the classic pattern used?


Thanks in advance,


Glen
-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101002/30c711f7/attachment.html>

From luca.pellicoro at gmail.com  Sat Oct  2 18:53:25 2010
From: luca.pellicoro at gmail.com (Luca Pellicoro)
Date: Sat, 2 Oct 2010 09:53:25 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
Message-ID: <AANLkTik=6gYQAa6gB7cLycq9KJ4GhZ3O7QMMrVa5vmXJ@mail.gmail.com>

Just ran into Pexpect a few minutes ago. Is this what you're looking for?
http://www.noah.org/wiki/Pexpect#Overview

On Sat, Oct 2, 2010 at 9:44 AM, Glen Jarvis <glen at glenjarvis.com> wrote:
> I've now seen a common problem come up several times. And, I imagine there
> is a common solution to this problem that I don't know.
> About a year ago, I wrote an automatic script that would automatically do an
> 'svn export' of certain branches of a tree depending upon what menu option
> the customer chose. When I did the svn export, I used subprocess.Popen.
> The pattern was similar to the following:
> print """This output is being buffered so I can read the version number.
>
> ? ? ....? I'm not stuck, just busy exporting files....
>
> """
>
> .....
>
> process = subprocess.Popen(['svn', 'export', repository,
> repo_name],?stdout=subprocess.PIPE, stderr=subprocess.PIPE)
>
> stdoutdata, stderrdata = process.communicate()
>
> I printed "please wait" and then printed the data given when the process was
> done (stdoutdata). It wasn't ideal but, it was sufficient for the time. If I
> were to have gone for the best fix, I would probably have learned the API
> for subversion to integrate directly into python.
> However, another BayPIGgie is having the same issue. He is using a command
> to start a CD burner from the command line and wants to print the output as
> it is being created from the command line.
> I can see that to solve this we wouldn't use the communicate() convenience
> function. A few 'hackish' ways that may solve this, but I'm looking for the
> common pattern that is used when other pythonista run up against this
> problem. I also want to ensure that I don't have a 'hack' that causes a
> deadlock only to discover this much later after I've implemented the pattern
> a few times.
> To help keep the conversation more focused, I've created two tiny test
> programs for a test case:
> 1) A C command line program that we have no control over changing within
> python, and
> 2) A Python program that calls that the c-program (baypiggies_demo):
> Compile command line so output is same as expected by Python program:
> gcc -pedantic baypiggies_demo.c -o baypiggies_demo
>
> ---- start of c program: File: baypiggies_demo.c?---
> #include <stdio.h>
> #include <unistd.h>
> int
> main()
> {
> ?? ?int ? ? ? ? ? ? i = 0;
> ?? ?printf("Silly output for monitoring...\n");
> ?? ?for (i = 0; i <= 10; i++) {
> ?? ? ? ?printf("Counting... %d\n", i);
> ?? ? ? ?sleep(1);
> ?? ?}
> }
> --- end of c program ---
>
>
> --- start of python program to demonstrate. File baypiggies.py ---
> import subprocess
> print "Just waiting...."
> process = subprocess.Popen(['./baypiggies_demo'],
> ?? ? ? ? ? ? ? ? ? ?stdout=subprocess.PIPE)
> stdoutdata, stderrdata = process.communicate()
> print "Well, NOW I get it.. :( "
> print stdoutdata
> --- end baypiggies.py --
>
>
> Has anyone else ran into this before? What's the classic pattern used?
>
> Thanks in advance,
>
> Glen
> --
> Whatever you can do or imagine, begin it;
> boldness has beauty, magic, and power in it.
>
> -- Goethe
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

From aahz at pythoncraft.com  Sat Oct  2 19:13:09 2010
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 2 Oct 2010 10:13:09 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
Message-ID: <20101002171309.GA4903@panix.com>

On Sat, Oct 02, 2010, Glen Jarvis wrote:
>
> I've now seen a common problem come up several times. And, I imagine there
> is a common solution to this problem that I don't know.

Could you explain what the problem is?  I think it's related to buffering
and pipes, but it's not clear from your post.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair

From glen at glenjarvis.com  Sat Oct  2 19:14:13 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Sat, 2 Oct 2010 10:14:13 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <686594.86681.qm@web34406.mail.mud.yahoo.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<686594.86681.qm@web34406.mail.mud.yahoo.com>
Message-ID: <AANLkTiknrD+-ch5enDyw3_v5JWs3Le_dc370NEWctS0S@mail.gmail.com>

What is needed is the input as it's being generated.

For example, the C-program counts to 10, with a second delay between each
count.

The python program, when it calls the C program, will have a 10 second delay
before it sees anything. Ideally, the python program can be printing the
results of the C program as they are being generated.


Thanks for asking for clarification...


Cheers,



Glen

On Sat, Oct 2, 2010 at 10:05 AM, joshua kaderlan <jkaderlan at yahoo.com>wrote:

> Reading this, it's not entirely clear what the problem is. Is it that
> subprocess.Popen buffers output, rather than returning it immediately the
> way os.system() does?
>
>
> *From:* Glen Jarvis <glen at glenjarvis.com>
> *To:* Baypiggies <baypiggies at python.org>
> *Sent:* Sat, October 2, 2010 9:44:05 AM
> *Subject:* [Baypiggies] Subprocess: Common problem/common pattern
>
> I've now seen a common problem come up several times. And, I imagine there
> is a common solution to this problem that I don't know.
>
> About a year ago, I wrote an automatic script that would automatically do
> an 'svn export' of certain branches of a tree depending upon what menu
> option the customer chose. When I did the svn export, I used
> subprocess.Popen.
>
> The pattern was similar to the following:
>
> print """This output is being buffered so I can read the version number.
>
>     ....  I'm not stuck, just busy exporting files....
>
> """
>
> .....
>
> process = subprocess.Popen(['svn', 'export', repository,
> repo_name], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
> stdoutdata, stderrdata = process.communicate()
>
>
> I printed "please wait" and then printed the data given when the process
> was done (stdoutdata). It wasn't ideal but, it was sufficient for the time.
> If I were to have gone for the best fix, I would probably have learned the
> API for subversion to integrate directly into python.
>
> However, another BayPIGgie is having the same issue. He is using a command
> to start a CD burner from the command line and wants to print the output as
> it is being created from the command line.
>
> I can see that to solve this we wouldn't use the communicate() convenience
> function. A few 'hackish' ways that may solve this, but I'm looking for the
> common pattern that is used when other pythonista run up against this
> problem. I also want to ensure that I don't have a 'hack' that causes a
> deadlock only to discover this much later after I've implemented the pattern
> a few times.
>
> To help keep the conversation more focused, I've created two tiny test
> programs for a test case:
> 1) A C command line program that we have no control over changing within
> python, and
> 2) A Python program that calls that the c-program (baypiggies_demo):
>
> Compile command line so output is same as expected by Python program:
> gcc -pedantic baypiggies_demo.c -o baypiggies_demo
>
>
> ---- start of c program: File: baypiggies_demo.c ---
> #include <stdio.h>
> #include <unistd.h>
>
> int
> main()
> {
>     int             i = 0;
>
>     printf("Silly output for monitoring...\n");
>     for (i = 0; i <= 10; i++) {
>         printf("Counting... %d\n", i);
>         sleep(1);
>     }
> }
> --- end of c program ---
>
>
>
> --- start of python program to demonstrate. File baypiggies.py ---
> import subprocess
>
> print "Just waiting...."
>
> process = subprocess.Popen(['./baypiggies_demo'],
>                     stdout=subprocess.PIPE)
>
> stdoutdata, stderrdata = process.communicate()
>
> print "Well, NOW I get it.. :( "
> print stdoutdata
> --- end baypiggies.py --
>
>
>
> Has anyone else ran into this before? What's the classic pattern used?
>
>
> Thanks in advance,
>
>
> Glen
> --
> Whatever you can do or imagine, begin it;
> boldness has beauty, magic, and power in it.
>
> -- Goethe
>
>
>


-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101002/41862674/attachment-0001.html>

From glen at glenjarvis.com  Sat Oct  2 19:17:37 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Sat, 2 Oct 2010 10:17:37 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <20101002171309.GA4903@panix.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<20101002171309.GA4903@panix.com>
Message-ID: <AANLkTimDERF2X31rh6O6i3gQ7Khuj4Qz05rJZ200Axs0@mail.gmail.com>

I'm sorry, I thought I was more clear with my test case. Obviously, I was
not.


The problem is this:

    Python programs can call subprocesses. The python program can wait until
the subprocess has finished and print the output captured. However, what we
want is to print the output immediately as it is generated.

    So, instead of waiting for the subprocess to finish, the python program
could continue -- printing the results as given by the subprocess.  From the
way the test case is written, the communicate() method will wait until the
subprocess is finished *before* it prints the results that were found.

Thanks for asking for clarification. You weren't the only person asking, so
obviously I wasn't clear enough in defining the problem.


Cheers,


Glen

On Sat, Oct 2, 2010 at 10:13 AM, Aahz <aahz at pythoncraft.com> wrote:

> On Sat, Oct 02, 2010, Glen Jarvis wrote:
> >
> > I've now seen a common problem come up several times. And, I imagine
> there
> > is a common solution to this problem that I don't know.
>
> Could you explain what the problem is?  I think it's related to buffering
> and pipes, but it's not clear from your post.
> --
> Aahz (aahz at pythoncraft.com)           <*>
> http://www.pythoncraft.com/
>
> "If you think it's expensive to hire a professional to do the job, wait
> until you hire an amateur."  --Red Adair
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>



-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101002/02e7508c/attachment.html>

From jtatum at gmail.com  Sat Oct  2 19:23:14 2010
From: jtatum at gmail.com (James Tatum)
Date: Sat, 2 Oct 2010 10:23:14 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTimDERF2X31rh6O6i3gQ7Khuj4Qz05rJZ200Axs0@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<20101002171309.GA4903@panix.com>
	<AANLkTimDERF2X31rh6O6i3gQ7Khuj4Qz05rJZ200Axs0@mail.gmail.com>
Message-ID: <AANLkTikL1WnKfm2DEEMGNDC99co9dRvDdPb-rLp0ZN=y@mail.gmail.com>

Google turns up a number of requests for this functionality, and a draft PEP[0].

Did you see this module[1]? It adds an event callback for subprocess output.

[0] http://www.python.org/dev/peps/pep-3145/
[1] http://code.activestate.com/recipes/576957-asynchronous-subprocess-using-asyncore/

On Sat, Oct 2, 2010 at 10:17 AM, Glen Jarvis <glen at glenjarvis.com> wrote:
> I'm sorry, I thought I was more clear with my test case. Obviously, I was
> not.
>
> The problem is this:
> ?? ?Python programs can call subprocesses. The python program can wait until
> the subprocess has finished and print the output captured. However, what we
> want is to print the output immediately as it is generated.
> ?? ?So, instead of waiting for the subprocess to finish, the python program
> could continue -- printing the results as given by the subprocess. ?From the
> way the test case is written, the communicate() method will wait until the
> subprocess is finished *before* it prints the results that were found.
> Thanks for asking for clarification. You weren't the only person asking, so
> obviously I wasn't clear enough in defining the problem.
>
> Cheers,
>
> Glen
> On Sat, Oct 2, 2010 at 10:13 AM, Aahz <aahz at pythoncraft.com> wrote:
>>
>> On Sat, Oct 02, 2010, Glen Jarvis wrote:
>> >
>> > I've now seen a common problem come up several times. And, I imagine
>> > there
>> > is a common solution to this problem that I don't know.
>>
>> Could you explain what the problem is? ?I think it's related to buffering
>> and pipes, but it's not clear from your post.
>> --
>> Aahz (aahz at pythoncraft.com) ? ? ? ? ? <*>
>> http://www.pythoncraft.com/
>>
>> "If you think it's expensive to hire a professional to do the job, wait
>> until you hire an amateur." ?--Red Adair
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> http://mail.python.org/mailman/listinfo/baypiggies
>
>
>
> --
> Whatever you can do or imagine, begin it;
> boldness has beauty, magic, and power in it.
>
> -- Goethe
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

From mamin at mbasciences.com  Sat Oct  2 19:23:40 2010
From: mamin at mbasciences.com (Minesh B. Amin)
Date: Sat, 02 Oct 2010 10:23:40 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
Message-ID: <1286040220.8837.13.camel@lusaka>

Hi Glen,

The are three general ways:

+ commands.getstatusoutput(...) 
     when you:
        * do not mind waiting for the command to finish
        * are interested in the stdout+stderr at the end (when the
command is finished)

+ pexpect < http://www.noah.org/wiki/Pexpect#Overview >
     when you:
        * want to interact with the launched command; e.g. enter login,
password, answer Y/N

     Thanks to pexpect, most of these interactions may be automated;
i.e.
     the python script may take over responsibility of processing
"login", "password" requests.

     Any interaction not automated may be passed on to the "human".

+ The solution "Capturing the Output and Error Streams from a 
     Unix Shell Command" from the book "Python Cookbook"

    when you:
      * want to simply consume the stderr/stdout of the launched command
in real-time

Hope this helps.

Cheers!
Minesh

On Sat, 2010-10-02 at 09:44 -0700, Glen Jarvis wrote:

> I've now seen a common problem come up several times. And, I imagine
> there is a common solution to this problem that I don't know.
> 
> 
> 
> About a year ago, I wrote an automatic script that would automatically
> do an 'svn export' of certain branches of a tree depending upon what
> menu option the customer chose. When I did the svn export, I used
> subprocess.Popen.
> 
> 
> The pattern was similar to the following:
> 
> 
> print """This output is being buffered so I can read the version
> number.
>     ....  I'm not stuck, just busy exporting files....
> 
> """
> 
> .....
> 
> process = subprocess.Popen(['svn', 'export', repository,
> repo_name], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
> 
> 
> stdoutdata, stderrdata = process.communicate()
> 
> 
> 
> 
> I printed "please wait" and then printed the data given when the
> process was done (stdoutdata). It wasn't ideal but, it was sufficient
> for the time. If I were to have gone for the best fix, I would
> probably have learned the API for subversion to integrate directly
> into python.
> 
> 
> However, another BayPIGgie is having the same issue. He is using a
> command to start a CD burner from the command line and wants to print
> the output as it is being created from the command line.
> 
> 
> I can see that to solve this we wouldn't use the communicate()
> convenience function. A few 'hackish' ways that may solve this, but
> I'm looking for the common pattern that is used when other pythonista
> run up against this problem. I also want to ensure that I don't have a
> 'hack' that causes a deadlock only to discover this much later after
> I've implemented the pattern a few times.
> 
> 
> To help keep the conversation more focused, I've created two tiny test
> programs for a test case:
> 1) A C command line program that we have no control over changing
> within python, and
> 2) A Python program that calls that the c-program (baypiggies_demo):
> 
> 
> Compile command line so output is same as expected by Python program:
> gcc -pedantic baypiggies_demo.c -o baypiggies_demo
> 
> 
> 
> 
> ---- start of c program: File: baypiggies_demo.c ---
> #include <stdio.h>
> #include <unistd.h>
> 
> 
> int
> main()
> {
>     int             i = 0;
> 
> 
>     printf("Silly output for monitoring...\n");
>     for (i = 0; i <= 10; i++) {
>         printf("Counting... %d\n", i);
>         sleep(1);
>     }
> }
> --- end of c program ---
> 
> 
> 
> 
> 
> 
> --- start of python program to demonstrate. File baypiggies.py ---
> import subprocess
> 
> 
> print "Just waiting...."
> 
> 
> process = subprocess.Popen(['./baypiggies_demo'],
>                     stdout=subprocess.PIPE)
> 
> 
> stdoutdata, stderrdata = process.communicate()
> 
> 
> print "Well, NOW I get it.. :( "
> print stdoutdata
> --- end baypiggies.py --
> 
> 
> 
> 
> 
> 
> Has anyone else ran into this before? What's the classic pattern used?
> 
> 
> 
> 
> Thanks in advance,
> 
> 
> 
> 
> Glen
> 
> -- 
> Whatever you can do or imagine, begin it;
> boldness has beauty, magic, and power in it.
> 
> -- Goethe 
> 
> 
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies


-- 
MBA Sciences, Inc (www.mbasciences.com)
Tel #: 650-938-4306
Email: mamin at mbasciences.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101002/8f9be849/attachment-0001.html>

From glen at glenjarvis.com  Sat Oct  2 19:26:31 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Sat, 2 Oct 2010 10:26:31 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTikL1WnKfm2DEEMGNDC99co9dRvDdPb-rLp0ZN=y@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<20101002171309.GA4903@panix.com>
	<AANLkTimDERF2X31rh6O6i3gQ7Khuj4Qz05rJZ200Axs0@mail.gmail.com>
	<AANLkTikL1WnKfm2DEEMGNDC99co9dRvDdPb-rLp0ZN=y@mail.gmail.com>
Message-ID: <AANLkTi=k6CDgN5ryNPKiaGTUOX-u8zcf1ihHWLnN2ygj@mail.gmail.com>

An event call back is *exactly* the kind of thing that I'm looking for. I
hadn't seen these yet... I'll review the PEPs now.

Thank you!


Glen

On Sat, Oct 2, 2010 at 10:23 AM, James Tatum <jtatum at gmail.com> wrote:

> Google turns up a number of requests for this functionality, and a draft
> PEP[0].
>
> Did you see this module[1]? It adds an event callback for subprocess
> output.
>
> [0] http://www.python.org/dev/peps/pep-3145/
> [1]
> http://code.activestate.com/recipes/576957-asynchronous-subprocess-using-asyncore/
>
> On Sat, Oct 2, 2010 at 10:17 AM, Glen Jarvis <glen at glenjarvis.com> wrote:
> > I'm sorry, I thought I was more clear with my test case. Obviously, I was
> > not.
> >
> > The problem is this:
> >     Python programs can call subprocesses. The python program can wait
> until
> > the subprocess has finished and print the output captured. However, what
> we
> > want is to print the output immediately as it is generated.
> >     So, instead of waiting for the subprocess to finish, the python
> program
> > could continue -- printing the results as given by the subprocess.  From
> the
> > way the test case is written, the communicate() method will wait until
> the
> > subprocess is finished *before* it prints the results that were found.
> > Thanks for asking for clarification. You weren't the only person asking,
> so
> > obviously I wasn't clear enough in defining the problem.
> >
> > Cheers,
> >
> > Glen
> > On Sat, Oct 2, 2010 at 10:13 AM, Aahz <aahz at pythoncraft.com> wrote:
> >>
> >> On Sat, Oct 02, 2010, Glen Jarvis wrote:
> >> >
> >> > I've now seen a common problem come up several times. And, I imagine
> >> > there
> >> > is a common solution to this problem that I don't know.
> >>
> >> Could you explain what the problem is?  I think it's related to
> buffering
> >> and pipes, but it's not clear from your post.
> >> --
> >> Aahz (aahz at pythoncraft.com)           <*>
> >> http://www.pythoncraft.com/
> >>
> >> "If you think it's expensive to hire a professional to do the job, wait
> >> until you hire an amateur."  --Red Adair
> >> _______________________________________________
> >> Baypiggies mailing list
> >> Baypiggies at python.org
> >> To change your subscription options or unsubscribe:
> >> http://mail.python.org/mailman/listinfo/baypiggies
> >
> >
> >
> > --
> > Whatever you can do or imagine, begin it;
> > boldness has beauty, magic, and power in it.
> >
> > -- Goethe
> >
> > _______________________________________________
> > Baypiggies mailing list
> > Baypiggies at python.org
> > To change your subscription options or unsubscribe:
> > http://mail.python.org/mailman/listinfo/baypiggies
> >
>



-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101002/66a455d1/attachment.html>

From jeremy.r.fishman at gmail.com  Sat Oct  2 19:27:15 2010
From: jeremy.r.fishman at gmail.com (Jeremy Fishman)
Date: Sat, 2 Oct 2010 10:27:15 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTiknrD+-ch5enDyw3_v5JWs3Le_dc370NEWctS0S@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<686594.86681.qm@web34406.mail.mud.yahoo.com>
	<AANLkTiknrD+-ch5enDyw3_v5JWs3Le_dc370NEWctS0S@mail.gmail.com>
Message-ID: <AANLkTik8tGzVyvV94SxkuBJV-6ep=g36mzCH+_DAB_GB@mail.gmail.com>

As Luca mentioned, there is pexpect.

If you don't want an external library dependency, and the underlying process
produces interactive output (and doesn't explicitly flush) the simplest
solution is to open a pseudo terminal.  There are several ways to interact
with the terminal, documented at http://docs.python.org/library/pty.html,
but here's one way I've coded before:

#!/usr/bin/python
import os
import pty
import subprocess as sp
import sys

# spawn subprocess with input/output connected to a pseudo-terminal
master, slave = pty.openpty()
tstP = sp.Popen(['/usr/bin/python','foo.py'], stdin=slave, stdout=slave,
                stderr=sp.STDOUT, close_fds=True)
# read an write on the terminal file descriptors
sys.stdout.write(os.read(master, 1024))
# we happily execute thanks to the pseudo-terminal
os.write(master, 'bar\n')
sys.stdout.write(os.read(master, 4096))

(foo.py)

#!/usr/bin/python
print "hello world"
foo = raw_input('? ')
print 'foo', foo


 - Jeremy


--
Jeremy R. Fishman
Developer @ Quantcast
jeremy.r.fishman at gmail.com

On Sat, Oct 2, 2010 at 10:14 AM, Glen Jarvis <glen at glenjarvis.com> wrote:

> What is needed is the input as it's being generated.
>
> For example, the C-program counts to 10, with a second delay between each
> count.
>
> The python program, when it calls the C program, will have a 10 second
> delay before it sees anything. Ideally, the python program can be printing
> the results of the C program as they are being generated.
>
>
> Thanks for asking for clarification...
>
>
> Cheers,
>
>
>
> Glen
>
> On Sat, Oct 2, 2010 at 10:05 AM, joshua kaderlan <jkaderlan at yahoo.com>wrote:
>
>> Reading this, it's not entirely clear what the problem is. Is it that
>> subprocess.Popen buffers output, rather than returning it immediately the
>> way os.system() does?
>>
>>
>> *From:* Glen Jarvis <glen at glenjarvis.com>
>> *To:* Baypiggies <baypiggies at python.org>
>> *Sent:* Sat, October 2, 2010 9:44:05 AM
>> *Subject:* [Baypiggies] Subprocess: Common problem/common pattern
>>
>> I've now seen a common problem come up several times. And, I imagine there
>> is a common solution to this problem that I don't know.
>>
>> About a year ago, I wrote an automatic script that would automatically do
>> an 'svn export' of certain branches of a tree depending upon what menu
>> option the customer chose. When I did the svn export, I used
>> subprocess.Popen.
>>
>> The pattern was similar to the following:
>>
>> print """This output is being buffered so I can read the version number.
>>
>>     ....  I'm not stuck, just busy exporting files....
>>
>> """
>>
>> .....
>>
>> process = subprocess.Popen(['svn', 'export', repository,
>> repo_name], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
>> stdoutdata, stderrdata = process.communicate()
>>
>>
>> I printed "please wait" and then printed the data given when the process
>> was done (stdoutdata). It wasn't ideal but, it was sufficient for the time.
>> If I were to have gone for the best fix, I would probably have learned the
>> API for subversion to integrate directly into python.
>>
>> However, another BayPIGgie is having the same issue. He is using a command
>> to start a CD burner from the command line and wants to print the output as
>> it is being created from the command line.
>>
>> I can see that to solve this we wouldn't use the communicate() convenience
>> function. A few 'hackish' ways that may solve this, but I'm looking for the
>> common pattern that is used when other pythonista run up against this
>> problem. I also want to ensure that I don't have a 'hack' that causes a
>> deadlock only to discover this much later after I've implemented the pattern
>> a few times.
>>
>> To help keep the conversation more focused, I've created two tiny test
>> programs for a test case:
>> 1) A C command line program that we have no control over changing within
>> python, and
>> 2) A Python program that calls that the c-program (baypiggies_demo):
>>
>> Compile command line so output is same as expected by Python program:
>> gcc -pedantic baypiggies_demo.c -o baypiggies_demo
>>
>>
>> ---- start of c program: File: baypiggies_demo.c ---
>> #include <stdio.h>
>> #include <unistd.h>
>>
>> int
>> main()
>> {
>>     int             i = 0;
>>
>>     printf("Silly output for monitoring...\n");
>>     for (i = 0; i <= 10; i++) {
>>         printf("Counting... %d\n", i);
>>         sleep(1);
>>     }
>> }
>> --- end of c program ---
>>
>>
>>
>> --- start of python program to demonstrate. File baypiggies.py ---
>> import subprocess
>>
>> print "Just waiting...."
>>
>> process = subprocess.Popen(['./baypiggies_demo'],
>>                     stdout=subprocess.PIPE)
>>
>> stdoutdata, stderrdata = process.communicate()
>>
>> print "Well, NOW I get it.. :( "
>> print stdoutdata
>> --- end baypiggies.py --
>>
>>
>>
>> Has anyone else ran into this before? What's the classic pattern used?
>>
>>
>> Thanks in advance,
>>
>>
>> Glen
>> --
>> Whatever you can do or imagine, begin it;
>> boldness has beauty, magic, and power in it.
>>
>> -- Goethe
>>
>>
>>
>
>
> --
> Whatever you can do or imagine, begin it;
> boldness has beauty, magic, and power in it.
>
> -- Goethe
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101002/9d164ae1/attachment-0001.html>

From glen at glenjarvis.com  Sat Oct  2 19:36:41 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Sat, 2 Oct 2010 10:36:41 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <1286040220.8837.13.camel@lusaka>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<1286040220.8837.13.camel@lusaka>
Message-ID: <AANLkTikuydWt9XEFVjnOnP1RC-+Xx+LHBpFFUVC0Lg92@mail.gmail.com>

Thanks Minesh... :)

I especially like your third choice. I didn't know this recipe was in the
Cookbook. Exactly what I was asking for. I've yanked the cookbook off the
shelf (and send my high praise to Alex for documenting this in advance as I
knew he know the answer to this)... I'll try to find the recipe in the
cookbook. I've also noticed a substantial amount of code sent by James
Tatum:

http://code.activestate.com/recipes/576957-asynchronous-subprocess-using-asyncore/

Now, I suddenly have a lot to review :)

Cheers,


Glen

On Sat, Oct 2, 2010 at 10:23 AM, Minesh B. Amin <mamin at mbasciences.com>wrote:

>  Hi Glen,
>
> The are three general ways:
>
> + commands.getstatusoutput(...)
>      when you:
>         * do not mind waiting for the command to finish
>         * are interested in the stdout+stderr at the end (when the command
> is finished)
>
> + pexpect < <http://www.noah.org/wiki/Pexpect#Overview>
> http://www.noah.org/wiki/Pexpect#Overview >
>      when you:
>         * want to interact with the launched command; e.g. enter login,
> password, answer Y/N
>
>      Thanks to pexpect, most of these interactions may be automated; i.e.
>      the python script may take over responsibility of processing "login",
> "password" requests.
>
>      Any interaction not automated may be passed on to the "human".
>
> + The solution "Capturing the Output and Error Streams from a
>      Unix Shell Command" from the book "Python Cookbook"
>
>     when you:
>       * want to simply consume the stderr/stdout of the launched command in
> real-time
>
> Hope this helps.
>
> Cheers!
> Minesh
>
>
> On Sat, 2010-10-02 at 09:44 -0700, Glen Jarvis wrote:
>
> I've now seen a common problem come up several times. And, I imagine there
> is a common solution to this problem that I don't know.
>
>
>
>  About a year ago, I wrote an automatic script that would automatically do
> an 'svn export' of certain branches of a tree depending upon what menu
> option the customer chose. When I did the svn export, I used
> subprocess.Popen.
>
>
>
>  The pattern was similar to the following:
>
>
>
>  print """This output is being buffered so I can read the version number.
>
>      ....  I'm not stuck, just busy exporting files....
>
> """
>
> .....
>
> process = subprocess.Popen(['svn', 'export', repository,
> repo_name], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
>
>
>  stdoutdata, stderrdata = process.communicate()
>
>
>
>
>
>  I printed "please wait" and then printed the data given when the process
> was done (stdoutdata). It wasn't ideal but, it was sufficient for the time.
> If I were to have gone for the best fix, I would probably have learned the
> API for subversion to integrate directly into python.
>
>
>
>  However, another BayPIGgie is having the same issue. He is using a
> command to start a CD burner from the command line and wants to print the
> output as it is being created from the command line.
>
>
>
>  I can see that to solve this we wouldn't use the communicate()
> convenience function. A few 'hackish' ways that may solve this, but I'm
> looking for the common pattern that is used when other pythonista run up
> against this problem. I also want to ensure that I don't have a 'hack' that
> causes a deadlock only to discover this much later after I've implemented
> the pattern a few times.
>
>
>
>  To help keep the conversation more focused, I've created two tiny test
> programs for a test case:
>
>  1) A C command line program that we have no control over changing within
> python, and
>
>  2) A Python program that calls that the c-program (baypiggies_demo):
>
>
>
>  Compile command line so output is same as expected by Python program:
>
>  gcc -pedantic baypiggies_demo.c -o baypiggies_demo
>
>
>
>
>  ---- start of c program: File: baypiggies_demo.c ---
>
>  #include <stdio.h>
>
>  #include <unistd.h>
>
>
>
>  int
>
>  main()
>
>  {
>
>      int             i = 0;
>
>
>
>      printf("Silly output for monitoring...\n");
>
>      for (i = 0; i <= 10; i++) {
>
>          printf("Counting... %d\n", i);
>
>          sleep(1);
>
>      }
>
>  }
>
>  --- end of c program ---
>
>
>
>
>
>
>
>  --- start of python program to demonstrate. File baypiggies.py ---
>
>  import subprocess
>
>
>
>  print "Just waiting...."
>
>
>
>  process = subprocess.Popen(['./baypiggies_demo'],
>
>                      stdout=subprocess.PIPE)
>
>
>
>  stdoutdata, stderrdata = process.communicate()
>
>
>
>  print "Well, NOW I get it.. :( "
>
>  print stdoutdata
>
>  --- end baypiggies.py --
>
>
>
>
>
>
>
>  Has anyone else ran into this before? What's the classic pattern used?
>
>
>
>
>
>  Thanks in advance,
>
>
>
>
>
>  Glen
>
>  --
> Whatever you can do or imagine, begin it;
> boldness has beauty, magic, and power in it.
>
> -- Goethe
>
>  _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:http://mail.python.org/mailman/listinfo/baypiggies
>
>
>   --
> MBA Sciences, Inc (www.mbasciences.com)
> Tel #: 650-938-4306
> Email: mamin at mbasciences.com
>
>


-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101002/6324b149/attachment.html>

From glen at glenjarvis.com  Sat Oct  2 19:37:48 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Sat, 2 Oct 2010 10:37:48 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTik8tGzVyvV94SxkuBJV-6ep=g36mzCH+_DAB_GB@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<686594.86681.qm@web34406.mail.mud.yahoo.com>
	<AANLkTiknrD+-ch5enDyw3_v5JWs3Le_dc370NEWctS0S@mail.gmail.com>
	<AANLkTik8tGzVyvV94SxkuBJV-6ep=g36mzCH+_DAB_GB@mail.gmail.com>
Message-ID: <AANLkTi=mS_WVnj0-HMjW2bYB_a7BQhQz0hz-X-MZ8N_-@mail.gmail.com>

Thanks, Jeremy!

Lots of options... Plenty for me to read and absorb now :)

Cheers,



Glen

On Sat, Oct 2, 2010 at 10:27 AM, Jeremy Fishman
<jeremy.r.fishman at gmail.com>wrote:

> As Luca mentioned, there is pexpect.
>
> If you don't want an external library dependency, and the underlying
> process produces interactive output (and doesn't explicitly flush) the
> simplest solution is to open a pseudo terminal.  There are several ways to
> interact with the terminal, documented at
> http://docs.python.org/library/pty.html, but here's one way I've coded
> before:
>
> #!/usr/bin/python
> import os
> import pty
> import subprocess as sp
> import sys
>
> # spawn subprocess with input/output connected to a pseudo-terminal
> master, slave = pty.openpty()
> tstP = sp.Popen(['/usr/bin/python','foo.py'], stdin=slave, stdout=slave,
>                 stderr=sp.STDOUT, close_fds=True)
> # read an write on the terminal file descriptors
> sys.stdout.write(os.read(master, 1024))
> # we happily execute thanks to the pseudo-terminal
> os.write(master, 'bar\n')
> sys.stdout.write(os.read(master, 4096))
>
> (foo.py)
>
>  #!/usr/bin/python
> print "hello world"
> foo = raw_input('? ')
> print 'foo', foo
>
>
>  - Jeremy
>
>
> --
> Jeremy R. Fishman
> Developer @ Quantcast
> jeremy.r.fishman at gmail.com
>
> On Sat, Oct 2, 2010 at 10:14 AM, Glen Jarvis <glen at glenjarvis.com> wrote:
>
>> What is needed is the input as it's being generated.
>>
>> For example, the C-program counts to 10, with a second delay between each
>> count.
>>
>> The python program, when it calls the C program, will have a 10 second
>> delay before it sees anything. Ideally, the python program can be printing
>> the results of the C program as they are being generated.
>>
>>
>> Thanks for asking for clarification...
>>
>>
>> Cheers,
>>
>>
>>
>> Glen
>>
>> On Sat, Oct 2, 2010 at 10:05 AM, joshua kaderlan <jkaderlan at yahoo.com>wrote:
>>
>>> Reading this, it's not entirely clear what the problem is. Is it that
>>> subprocess.Popen buffers output, rather than returning it immediately the
>>> way os.system() does?
>>>
>>>
>>> *From:* Glen Jarvis <glen at glenjarvis.com>
>>> *To:* Baypiggies <baypiggies at python.org>
>>> *Sent:* Sat, October 2, 2010 9:44:05 AM
>>> *Subject:* [Baypiggies] Subprocess: Common problem/common pattern
>>>
>>> I've now seen a common problem come up several times. And, I imagine
>>> there is a common solution to this problem that I don't know.
>>>
>>> About a year ago, I wrote an automatic script that would automatically do
>>> an 'svn export' of certain branches of a tree depending upon what menu
>>> option the customer chose. When I did the svn export, I used
>>> subprocess.Popen.
>>>
>>> The pattern was similar to the following:
>>>
>>> print """This output is being buffered so I can read the version number.
>>>
>>>     ....  I'm not stuck, just busy exporting files....
>>>
>>> """
>>>
>>> .....
>>>
>>> process = subprocess.Popen(['svn', 'export', repository,
>>> repo_name], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
>>> stdoutdata, stderrdata = process.communicate()
>>>
>>>
>>> I printed "please wait" and then printed the data given when the process
>>> was done (stdoutdata). It wasn't ideal but, it was sufficient for the time.
>>> If I were to have gone for the best fix, I would probably have learned the
>>> API for subversion to integrate directly into python.
>>>
>>> However, another BayPIGgie is having the same issue. He is using a
>>> command to start a CD burner from the command line and wants to print the
>>> output as it is being created from the command line.
>>>
>>> I can see that to solve this we wouldn't use the communicate()
>>> convenience function. A few 'hackish' ways that may solve this, but I'm
>>> looking for the common pattern that is used when other pythonista run up
>>> against this problem. I also want to ensure that I don't have a 'hack' that
>>> causes a deadlock only to discover this much later after I've implemented
>>> the pattern a few times.
>>>
>>> To help keep the conversation more focused, I've created two tiny test
>>> programs for a test case:
>>> 1) A C command line program that we have no control over changing within
>>> python, and
>>> 2) A Python program that calls that the c-program (baypiggies_demo):
>>>
>>> Compile command line so output is same as expected by Python program:
>>> gcc -pedantic baypiggies_demo.c -o baypiggies_demo
>>>
>>>
>>> ---- start of c program: File: baypiggies_demo.c ---
>>> #include <stdio.h>
>>> #include <unistd.h>
>>>
>>> int
>>> main()
>>> {
>>>     int             i = 0;
>>>
>>>     printf("Silly output for monitoring...\n");
>>>     for (i = 0; i <= 10; i++) {
>>>         printf("Counting... %d\n", i);
>>>         sleep(1);
>>>     }
>>> }
>>> --- end of c program ---
>>>
>>>
>>>
>>> --- start of python program to demonstrate. File baypiggies.py ---
>>> import subprocess
>>>
>>> print "Just waiting...."
>>>
>>> process = subprocess.Popen(['./baypiggies_demo'],
>>>                     stdout=subprocess.PIPE)
>>>
>>> stdoutdata, stderrdata = process.communicate()
>>>
>>> print "Well, NOW I get it.. :( "
>>> print stdoutdata
>>> --- end baypiggies.py --
>>>
>>>
>>>
>>> Has anyone else ran into this before? What's the classic pattern used?
>>>
>>>
>>> Thanks in advance,
>>>
>>>
>>> Glen
>>> --
>>> Whatever you can do or imagine, begin it;
>>> boldness has beauty, magic, and power in it.
>>>
>>> -- Goethe
>>>
>>>
>>>
>>
>>
>> --
>> Whatever you can do or imagine, begin it;
>> boldness has beauty, magic, and power in it.
>>
>> -- Goethe
>>
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> http://mail.python.org/mailman/listinfo/baypiggies
>>
>
>


-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101002/4857e914/attachment-0001.html>

From bpederse at gmail.com  Sat Oct  2 20:05:32 2010
From: bpederse at gmail.com (Brent Pedersen)
Date: Sat, 2 Oct 2010 11:05:32 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
Message-ID: <AANLkTimWmt3wsoptzg+m0EXB8D5mfiDgP7kX42Sw5WNe@mail.gmail.com>

On Sat, Oct 2, 2010 at 9:44 AM, Glen Jarvis <glen at glenjarvis.com> wrote:
> I've now seen a common problem come up several times. And, I imagine there
> is a common solution to this problem that I don't know.
> About a year ago, I wrote an automatic script that would automatically do an
> 'svn export' of certain branches of a tree depending upon what menu option
> the customer chose. When I did the svn export, I used subprocess.Popen.
> The pattern was similar to the following:
> print """This output is being buffered so I can read the version number.
>
> ? ? ....? I'm not stuck, just busy exporting files....
>
> """
>
> .....
>
> process = subprocess.Popen(['svn', 'export', repository,
> repo_name],?stdout=subprocess.PIPE, stderr=subprocess.PIPE)
>
> stdoutdata, stderrdata = process.communicate()
>
> I printed "please wait" and then printed the data given when the process was
> done (stdoutdata). It wasn't ideal but, it was sufficient for the time. If I
> were to have gone for the best fix, I would probably have learned the API
> for subversion to integrate directly into python.
> However, another BayPIGgie is having the same issue. He is using a command
> to start a CD burner from the command line and wants to print the output as
> it is being created from the command line.
> I can see that to solve this we wouldn't use the communicate() convenience
> function. A few 'hackish' ways that may solve this, but I'm looking for the
> common pattern that is used when other pythonista run up against this
> problem. I also want to ensure that I don't have a 'hack' that causes a
> deadlock only to discover this much later after I've implemented the pattern
> a few times.
> To help keep the conversation more focused, I've created two tiny test
> programs for a test case:
> 1) A C command line program that we have no control over changing within
> python, and
> 2) A Python program that calls that the c-program (baypiggies_demo):
> Compile command line so output is same as expected by Python program:
> gcc -pedantic baypiggies_demo.c -o baypiggies_demo
>
> ---- start of c program: File: baypiggies_demo.c?---
> #include <stdio.h>
> #include <unistd.h>
> int
> main()
> {
> ?? ?int ? ? ? ? ? ? i = 0;
> ?? ?printf("Silly output for monitoring...\n");
> ?? ?for (i = 0; i <= 10; i++) {
> ?? ? ? ?printf("Counting... %d\n", i);
> ?? ? ? ?sleep(1);
> ?? ?}
> }
> --- end of c program ---
>
>
> --- start of python program to demonstrate. File baypiggies.py ---
> import subprocess
> print "Just waiting...."
> process = subprocess.Popen(['./baypiggies_demo'],
> ?? ? ? ? ? ? ? ? ? ?stdout=subprocess.PIPE)
> stdoutdata, stderrdata = process.communicate()
> print "Well, NOW I get it.. :( "
> print stdoutdata
> --- end baypiggies.py --
>
>
> Has anyone else ran into this before? What's the classic pattern used?
>
> Thanks in advance,
>
> Glen
> --
> Whatever you can do or imagine, begin it;
> boldness has beauty, magic, and power in it.
>
> -- Goethe
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

i've had this problem as well. by my reading of the docs, you're
supposed to be able to get line-buffered output by setting bufsize=1,
but it seems there's some minimum number of characters that needs to
get sent as well. i can make your example show incrementally in python
by adding a hacky line to your c code:
        for (j = 0; j < 16384; j++){ printf(" "); }

where 16384 is just an arbitrary choice to add enough chars to the stream.
then using the python code:

p = subprocess.Popen(['./a.out'], stdout=subprocess.PIPE, bufsize=1,
shell=True)
for line in p.stdout:
    print line.strip()


clearly, that doesn't solve your problem, but it does work when you're
streaming large amounts of data. i'd be interested to know what you
come up with as a solution.

From bpalmer at gmail.com  Sat Oct  2 21:24:05 2010
From: bpalmer at gmail.com (Brian Palmer)
Date: Sat, 2 Oct 2010 12:24:05 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTimWmt3wsoptzg+m0EXB8D5mfiDgP7kX42Sw5WNe@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<AANLkTimWmt3wsoptzg+m0EXB8D5mfiDgP7kX42Sw5WNe@mail.gmail.com>
Message-ID: <AANLkTinn+mMCjouMUbEPt_czpgJYxxSkJ5ovCL=JwSsi@mail.gmail.com>

On Sat, Oct 2, 2010 at 11:05 AM, Brent Pedersen <bpederse at gmail.com> wrote:

> i've had this problem as well. by my reading of the docs, you're
> supposed to be able to get line-buffered output by setting bufsize=1,
> but it seems there's some minimum number of characters that needs to
> get sent as well. i can make your example show incrementally in python
> by adding a hacky line to your c code:
>        for (j = 0; j < 16384; j++){ printf(" "); }
>

You have to consider buffering on both the input and output sides of a pipe.
By default, your C library is probably buffering stdout in a pipeline to
some large blocksize.
If you changed the printf statements to be fprintf(stderr,  ...) instead,
you probably wouldn't need do that; by default, stderr will be flushed after
each newline. To work around this,
the calling process can set up a pseudo-tty to "fool" the executing program
into thinking it's not in a pipeline. This is just one of the things that
pexpect can offer you. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101002/db6a05af/attachment.html>

From bpederse at gmail.com  Sat Oct  2 21:55:31 2010
From: bpederse at gmail.com (Brent Pedersen)
Date: Sat, 2 Oct 2010 12:55:31 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTinn+mMCjouMUbEPt_czpgJYxxSkJ5ovCL=JwSsi@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<AANLkTimWmt3wsoptzg+m0EXB8D5mfiDgP7kX42Sw5WNe@mail.gmail.com>
	<AANLkTinn+mMCjouMUbEPt_czpgJYxxSkJ5ovCL=JwSsi@mail.gmail.com>
Message-ID: <AANLkTikuJHTYYJTc2ejz1hE5qpUAEN0nJapCiGzs=-sC@mail.gmail.com>

On Sat, Oct 2, 2010 at 12:24 PM, Brian Palmer <bpalmer at gmail.com> wrote:
> On Sat, Oct 2, 2010 at 11:05 AM, Brent Pedersen <bpederse at gmail.com> wrote:
>>
>> i've had this problem as well. by my reading of the docs, you're
>> supposed to be able to get line-buffered output by setting bufsize=1,
>> but it seems there's some minimum number of characters that needs to
>> get sent as well. i can make your example show incrementally in python
>> by adding a hacky line to your c code:
>> ? ? ? ?for (j = 0; j < 16384; j++){ printf(" "); }
>
> You have to consider buffering on both the input and output sides of a pipe.
> By default, your C library is probably buffering stdout in a pipeline to
> some large blocksize.

maybe i'm not doing it correctly, but i have (and had previoulsy)
tried (the equivalent of) adding fflush(stdout) to glenn's example
with no change. if you can show an example where that works, i'll
definitely be happy for the knowledge.

> If you changed the printf statements to be fprintf(stderr,? ...) instead,
> you probably wouldn't need do that; by default, stderr will be flushed after
> each newline. To work around this,
> the calling process can set up a pseudo-tty to "fool" the executing program
> into thinking it's not in a pipeline. This is just one of the things that
> pexpect can offer you. :)
>

yeah, that seems to be the way to go. thanks.

From keith at dartworks.biz  Mon Oct  4 02:00:57 2010
From: keith at dartworks.biz (Keith Dart)
Date: Sun, 3 Oct 2010 17:00:57 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTinn+mMCjouMUbEPt_czpgJYxxSkJ5ovCL=JwSsi@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<AANLkTimWmt3wsoptzg+m0EXB8D5mfiDgP7kX42Sw5WNe@mail.gmail.com>
	<AANLkTinn+mMCjouMUbEPt_czpgJYxxSkJ5ovCL=JwSsi@mail.gmail.com>
Message-ID: <20101003170057.2b1f0d45@dartworks.biz>

=== On Sat, 10/02, Brian Palmer wrote: ===
> You have to consider buffering on both the input and output sides of
> a pipe. By default, your C library is probably buffering stdout in a
> pipeline to some large blocksize.
===

In these cases it's the kernel that is buffering the pipe. On Linux
that seems to be about 4K. If the parent process does not read it's end
the buffer will fill up and the subprocess with block on I/O. The
parent process can either do a blocking read on the its side of the
pipe or pty (master side), or use select/poll/epoll to check for
available input. 

This kind of I/O bound stuff is what twisted is good at. I would
suggest you learn that, and look at twisted-runner. 

An alternative is pexpect. But I use pycopia.expect :-)




-- Keith Dart

-- 
-- ------------------------------
Keith Dart
=================================


From wescpy at gmail.com  Mon Oct  4 18:25:56 2010
From: wescpy at gmail.com (wesley chun)
Date: Mon, 4 Oct 2010 09:25:56 -0700
Subject: [Baypiggies] Silicon Valley Code Camp this wknd!
Message-ID: <AANLkTin=Jkn3R7-ysZ9D=d1F72yLFxf0w-Y0=hLoAuc0@mail.gmail.com>

all,

as i mentioned at the meeting last week, Silicon Valley CodeCamp is
this coming weekend!! it's a free local technical conference with free
food & drink, doesn't involve (much) travel, and you don't have to
take time off of work, so what's not to love (except you consuming
your precious wknd)?!?

it's getting full fast, so register quickly:
http://siliconvalley-codecamp.com

there are many Python-flavored talks:
http://www.siliconvalley-codecamp.com/Sessions.aspx?sortby=title&by=category&tag=59

i've even organized an entire track for Google technologies:
http://www.siliconvalley-codecamp.com/Sessions.aspx?track=18

since the whole thing is done in a "barcamp"-style fashion, it's very
much a grassroots effort still, so if you have some cycles, please
volunteer (see msg below) to help too! then you'll feel much better
about getting so much valuable information at the event... plus you
get a free "staff" t-shirt to show off! :-)

cheers, and see you there!
-wesley


---------- Forwarded message ----------
From:  <service at siliconvalley-codecamp.com>
Date: Fri, Oct 1, 2010 at 2:14 PM
Subject: We Need Volunteers for Silicon Valley Code Camp!

SVCC needs your help. ?This year's event is bigger and better than
ever and we need more helping hands to make things run smoothly.
Volunteering has so many benefits, the chance to meet and work with
others like you, that feeling of goodness knowing you are contributing
to an all-volunteer technology event, plus you're invited to attend
the speaker appreciation dinner on Saturday and you'll get a cool
T-shirt. ?All this for just a couple hours of your time.

Our procedure this year for volunteering has changed. ?Instead of
going to a wiki like the past 4 years, we've baked the jobs into the
silicon valley code camp web site. ?If you want to volunteer, you need
to update your registration page to let us know that at
http://siliconvalley-codecamp.com/Register.aspx?PKID=88aec9bb-514a-419c-87fd-3d93338641e3
(assuming you have not done that already).

This registration page requires you to check the box at the bottom to
volunteer, as well as put a contact mobile phone number that we can
reach you on at the event itself. ?Then, after you have updated your
registration, go to this page:
http://siliconvalley-codecamp.com/VolunteerForJob.aspx and pick the
job(s) you are interested in doing.

Most of the jobs are 1 hour with a 15 minute overlap to train the next
volunteer. A few jobs are longer 1.5 hours. We'd really appreciate
volunteers who can handle 2 slots (back-to-back on Registration, which
would effectively be about 2 hours)

See you next week!

Peter Kellner
http://peterkellner.net
SV Code Camp Coordinator


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", Prentice Hall, (c)2007,2001
"Python Fundamentals", Prentice Hall, (c)2009
? ? http://corepython.com

wesley.j.chun :: wescpy-at-gmail.com
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com

From bbdada at gmail.com  Wed Oct  6 04:15:50 2010
From: bbdada at gmail.com (Nick S Kanakakorn)
Date: Tue, 5 Oct 2010 19:15:50 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
Message-ID: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>

Hi,

My work place has imposed a rules for no use of exception (catching is
allowed).  If I have code like this

def f1()
  if bad_thing_happen():
     raise Exception('bad stuff')
  ...
  return something

I could change it to

def f1()
  if bad_thing_happen():
    return [-1, None]
  ...
  return [0, something]

f1 caller would be like this

def f1_caller():
  code, result = f1(param1)
  if code < 0:
    return code
  actual_work1()
  # call f1 again
  code, result = f1(param2)
  if code < 0:
    return code
  actual_work2()
  ...

Are there more elegant ways than this in Python ?

Thanks,
Nick K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101005/40b6c7cd/attachment.html>

From glen at glenjarvis.com  Wed Oct  6 04:27:56 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Tue, 5 Oct 2010 19:27:56 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
Message-ID: <BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>


> My work place has imposed a rules for no use of exception (catching is allowed).

What?!?

Forgive my reaction, I'm just very surprised. Why has your workplace implemented this policy? Has anyone else on BayPIGgies seen a  policy like this? What's the rationale?  Am I a Luddite for not hearing on this?

I'm sorry. I know you asked a genuine question and I haven't answered it. I just found this very odd and am first getting my head around the question.

Cheers,


Glen


From daniel at djansoft.com  Wed Oct  6 04:45:31 2010
From: daniel at djansoft.com (=?ISO-8859-1?Q?Daniel_Gonz=E1lez_Gasull?=)
Date: Tue, 5 Oct 2010 19:45:31 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
Message-ID: <AANLkTik1eOGjVEsx05FgHCMoUh0p4s=u6SKZaXGak6Rc@mail.gmail.com>

I agree.  That's an anti-pattern:

http://today.java.net/article/2006/04/04/exception-handling-antipatterns

The article is about Java, but it applies anyway.  See where it says
"Log and Return Null".


On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <glen at glenjarvis.com> wrote:
>
>> My work place has imposed a rules for no use of exception (catching is allowed).
>
> What?!?
>
> Forgive my reaction, I'm just very surprised. Why has your workplace implemented this policy? Has anyone else on BayPIGgies seen a ?policy like this? What's the rationale? ?Am I a Luddite for not hearing on this?
>
> I'm sorry. I know you asked a genuine question and I haven't answered it. I just found this very odd and am first getting my head around the question.
>
> Cheers,
>
>
> Glen
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>



-- 
http://DjanSoft.com :: Agile Application Development with Python

From recursive.cookie.jar at gmail.com  Wed Oct  6 04:51:01 2010
From: recursive.cookie.jar at gmail.com (Zachary Collins)
Date: Tue, 5 Oct 2010 22:51:01 -0400
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTik1eOGjVEsx05FgHCMoUh0p4s=u6SKZaXGak6Rc@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
	<AANLkTik1eOGjVEsx05FgHCMoUh0p4s=u6SKZaXGak6Rc@mail.gmail.com>
Message-ID: <AANLkTintXwyJ=9iB99AbyShPRm6+3LFdx5oc9=iDP=1P@mail.gmail.com>

I know.  You should devise a way for your f1_caller to be able to
determine if there's an issue inside of f1, and have it just
automatically back out of f1_caller itself, and then inform the caller
of f1_caller.  Something that you could just add inside of f1 in one
place, that informed as far back in the stack as is responsible for
the data issue in f1.  Something that maybe allowed you to make caller
functions aware of an error, elegantly... hmmmmmmmm

2010/10/5 Daniel Gonz?lez Gasull <daniel at djansoft.com>:
> I agree. ?That's an anti-pattern:
>
> http://today.java.net/article/2006/04/04/exception-handling-antipatterns
>
> The article is about Java, but it applies anyway. ?See where it says
> "Log and Return Null".
>
>
> On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <glen at glenjarvis.com> wrote:
>>
>>> My work place has imposed a rules for no use of exception (catching is allowed).
>>
>> What?!?
>>
>> Forgive my reaction, I'm just very surprised. Why has your workplace implemented this policy? Has anyone else on BayPIGgies seen a ?policy like this? What's the rationale? ?Am I a Luddite for not hearing on this?
>>
>> I'm sorry. I know you asked a genuine question and I haven't answered it. I just found this very odd and am first getting my head around the question.
>>
>> Cheers,
>>
>>
>> Glen
>>
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> http://mail.python.org/mailman/listinfo/baypiggies
>>
>
>
>
> --
> http://DjanSoft.com :: Agile Application Development with Python
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

From bbdada at gmail.com  Wed Oct  6 05:42:21 2010
From: bbdada at gmail.com (Nick S Kanakakorn)
Date: Tue, 5 Oct 2010 20:42:21 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
Message-ID: <AANLkTi=TQ=aUQOX9zLHCxh3XmvuFERfhs8qCYJHikBB=@mail.gmail.com>

Let's skip the rationale discussion although I feel better for your
sympathy.  One non python solution I can think of is Macro (C/C++) or add a
new command  which could work in any stack frame (TCL).
However, I'm quite new to python so I'm not so sure if there are some ways
around this.

Can we have something similar to macro in python ?

On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <glen at glenjarvis.com> wrote:

>
> > My work place has imposed a rules for no use of exception (catching is
> allowed).
>
> What?!?
>
> Forgive my reaction, I'm just very surprised. Why has your workplace
> implemented this policy? Has anyone else on BayPIGgies seen a  policy like
> this? What's the rationale?  Am I a Luddite for not hearing on this?
>
> I'm sorry. I know you asked a genuine question and I haven't answered it. I
> just found this very odd and am first getting my head around the question.
>
> Cheers,
>
>
> Glen
>
>


-- 
-Nick Kanakakorn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101005/d10b8eb6/attachment.html>

From jtatum at gmail.com  Wed Oct  6 05:57:03 2010
From: jtatum at gmail.com (James Tatum)
Date: Tue, 5 Oct 2010 20:57:03 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
Message-ID: <AANLkTi=jKHF9zHaPG=1SZngW+w=kSW8o9QxMcM16rm3z@mail.gmail.com>

On Tue, Oct 5, 2010 at 7:15 PM, Nick S Kanakakorn <bbdada at gmail.com> wrote:
> Hi,
> My work place has imposed a rules for no use of exception (catching is
> allowed). ?If I have code like this

I've seen this anti-pattern up close. There is no Pythonic answer -
exceptions are the answer. I've adapted this recipe[0] to get all
kinds of information from the call stack when something fails,
although it depends on the failing function to call it... Definitely a
pain. I feel for you. Hopefully the code is solid enough not to need
too much debugging.

For the curious, the rationale I heard is that failure isn't important
enough to stop the execution or the minor variant, failures are
irrelevant to the execution.

[0] http://code.activestate.com/recipes/52215/

From tungwaiyip at yahoo.com  Wed Oct  6 06:03:25 2010
From: tungwaiyip at yahoo.com (Tung Wai Yip)
Date: Tue, 05 Oct 2010 21:03:25 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTi=TQ=aUQOX9zLHCxh3XmvuFERfhs8qCYJHikBB=@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
	<AANLkTi=TQ=aUQOX9zLHCxh3XmvuFERfhs8qCYJHikBB=@mail.gmail.com>
Message-ID: <op.vj4yvypaoiuain@smtp.mail.yahoo.com>

Why do you want to do this? Is this just an internal coding guideline? Or  
is it done for interfacing to another language or running on non-standard  
VM? Is this apply to new code only or do you want to update existing code  
as well?

There is no equivalent of C macro in Python. Just apply every code change  
as you describe it. Build a tuple every time you return something. Change  
raise into returning tuple. And change ever function call to expecting a  
tuple return value. I can't think of anything smarter. it looks like a  
complete disaster anyway.

Wai yip



> Let's skip the rationale discussion although I feel better for your
> sympathy.  One non python solution I can think of is Macro (C/C++) or  
> add a
> new command  which could work in any stack frame (TCL).
> However, I'm quite new to python so I'm not so sure if there are some  
> ways
> around this.
>
> Can we have something similar to macro in python ?
>
> On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <glen at glenjarvis.com> wrote:
>
>>
>> > My work place has imposed a rules for no use of exception (catching is
>> allowed).
>>
>> What?!?
>>
>> Forgive my reaction, I'm just very surprised. Why has your workplace
>> implemented this policy? Has anyone else on BayPIGgies seen a  policy  
>> like
>> this? What's the rationale?  Am I a Luddite for not hearing on this?
>>
>> I'm sorry. I know you asked a genuine question and I haven't answered  
>> it. I
>> just found this very odd and am first getting my head around the  
>> question.
>>
>> Cheers,
>>
>>
>> Glen
>>
>>
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From bbdada at gmail.com  Wed Oct  6 06:16:59 2010
From: bbdada at gmail.com (Nick S Kanakakorn)
Date: Tue, 5 Oct 2010 21:16:59 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <op.vj4yvypaoiuain@smtp.mail.yahoo.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
	<AANLkTi=TQ=aUQOX9zLHCxh3XmvuFERfhs8qCYJHikBB=@mail.gmail.com>
	<op.vj4yvypaoiuain@smtp.mail.yahoo.com>
Message-ID: <AANLkTik=M0ekzKGe8hVRvybevV46rVe4yUmk3WAvP=ux@mail.gmail.com>

I don't want to do this.  There is someone that against throwing exception
and that person has more seniority than me. He put in a guideline.  I lost
in the debate.  There is no proper research done and all the decisions were
made in less than 1 day.

On Tue, Oct 5, 2010 at 9:03 PM, Tung Wai Yip <tungwaiyip at yahoo.com> wrote:

> Why do you want to do this? Is this just an internal coding guideline? Or
> is it done for interfacing to another language or running on non-standard
> VM? Is this apply to new code only or do you want to update existing code as
> well?
>
> There is no equivalent of C macro in Python. Just apply every code change
> as you describe it. Build a tuple every time you return something. Change
> raise into returning tuple. And change ever function call to expecting a
> tuple return value. I can't think of anything smarter. it looks like a
> complete disaster anyway.
>
> Wai yip
>
>
>
>
>  Let's skip the rationale discussion although I feel better for your
>> sympathy.  One non python solution I can think of is Macro (C/C++) or add
>> a
>> new command  which could work in any stack frame (TCL).
>> However, I'm quite new to python so I'm not so sure if there are some ways
>> around this.
>>
>> Can we have something similar to macro in python ?
>>
>> On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <glen at glenjarvis.com> wrote:
>>
>>
>>> > My work place has imposed a rules for no use of exception (catching is
>>> allowed).
>>>
>>> What?!?
>>>
>>> Forgive my reaction, I'm just very surprised. Why has your workplace
>>> implemented this policy? Has anyone else on BayPIGgies seen a  policy
>>> like
>>> this? What's the rationale?  Am I a Luddite for not hearing on this?
>>>
>>> I'm sorry. I know you asked a genuine question and I haven't answered it.
>>> I
>>> just found this very odd and am first getting my head around the
>>> question.
>>>
>>> Cheers,
>>>
>>>
>>> Glen
>>>
>>>
>>>
>>
>>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>



-- 
-Nick Kanakakorn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101005/c0376584/attachment.html>

From tungwaiyip at yahoo.com  Wed Oct  6 06:20:35 2010
From: tungwaiyip at yahoo.com (Tung Wai Yip)
Date: Tue, 05 Oct 2010 21:20:35 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTi=jKHF9zHaPG=1SZngW+w=kSW8o9QxMcM16rm3z@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<AANLkTi=jKHF9zHaPG=1SZngW+w=kSW8o9QxMcM16rm3z@mail.gmail.com>
Message-ID: <op.vj4zok0roiuain@smtp.mail.yahoo.com>

The recipe only collect information from the stack. It won't resume  
execution after an exception is throw.

It maybe easier to use a wrapper for all function call.


>>> def call(func, *args, **kwargs):
...   try:
...     return func(*args,**kwargs)
...   except:
...     # auto ignore exception!
...     return
...
>>> res = call(open,'dummy file','rb')
>>> # look mom, no exception!

Wai Yip



> On Tue, Oct 5, 2010 at 7:15 PM, Nick S Kanakakorn <bbdada at gmail.com>  
> wrote:
>> Hi,
>> My work place has imposed a rules for no use of exception (catching is
>> allowed).  If I have code like this
>
> I've seen this anti-pattern up close. There is no Pythonic answer -
> exceptions are the answer. I've adapted this recipe[0] to get all
> kinds of information from the call stack when something fails,
> although it depends on the failing function to call it... Definitely a
> pain. I feel for you. Hopefully the code is solid enough not to need
> too much debugging.
>
> For the curious, the rationale I heard is that failure isn't important
> enough to stop the execution or the minor variant, failures are
> irrelevant to the execution.
>
> [0] http://code.activestate.com/recipes/52215/
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From slacy at slacy.com  Wed Oct  6 06:32:48 2010
From: slacy at slacy.com (Stephen Lacy)
Date: Tue, 5 Oct 2010 21:32:48 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <op.vj4zok0roiuain@smtp.mail.yahoo.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<AANLkTi=jKHF9zHaPG=1SZngW+w=kSW8o9QxMcM16rm3z@mail.gmail.com>
	<op.vj4zok0roiuain@smtp.mail.yahoo.com>
Message-ID: <AANLkTi=w4AT1mQyNwjZ7oYUSyT5bWvTLtH1E1M6BrOfU@mail.gmail.com>

If you're not allowed to raise the exception, why not just return it?

I can imagine a pattern where every function was a tuple return value (as
stated previously) where the first item is the real return value, and the
2nd item is either None or an instance of an Exception.

Then, you could wrap every function in your entire system with a decorator
that looked at these return values, and if the Exception part was non-None,
then it would return back out to the caller, possibly calling some cleanup
function that would be specified as an argument to the decorator.  I can
code up some kind of rudimentary example if you'd like.

Of course, this path gets dangerously close to "let's do exactly the same
thing as exceptions but not use the built in language features ourselves and
rewrite the whole thing from scratch so we have a maintenance nightmare".

Is it too late to quit and go work somewhere else?

Steve

On Tue, Oct 5, 2010 at 9:20 PM, Tung Wai Yip <tungwaiyip at yahoo.com> wrote:

> The recipe only collect information from the stack. It won't resume
> execution after an exception is throw.
>
> It maybe easier to use a wrapper for all function call.
>
>
>  def call(func, *args, **kwargs):
>>>>
>>> ...   try:
> ...     return func(*args,**kwargs)
> ...   except:
> ...     # auto ignore exception!
> ...     return
> ...
>
>> res = call(open,'dummy file','rb')
>>>> # look mom, no exception!
>>>>
>>>
> Wai Yip
>
>
>
>
>  On Tue, Oct 5, 2010 at 7:15 PM, Nick S Kanakakorn <bbdada at gmail.com>
>> wrote:
>>
>>> Hi,
>>> My work place has imposed a rules for no use of exception (catching is
>>> allowed).  If I have code like this
>>>
>>
>> I've seen this anti-pattern up close. There is no Pythonic answer -
>> exceptions are the answer. I've adapted this recipe[0] to get all
>> kinds of information from the call stack when something fails,
>> although it depends on the failing function to call it... Definitely a
>> pain. I feel for you. Hopefully the code is solid enough not to need
>> too much debugging.
>>
>> For the curious, the rationale I heard is that failure isn't important
>> enough to stop the execution or the minor variant, failures are
>> irrelevant to the execution.
>>
>> [0] http://code.activestate.com/recipes/52215/
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> http://mail.python.org/mailman/listinfo/baypiggies
>>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101005/444fb126/attachment-0001.html>

From andywiggin at gmail.com  Wed Oct  6 06:42:12 2010
From: andywiggin at gmail.com (Andy Wiggin)
Date: Tue, 5 Oct 2010 21:42:12 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTik=M0ekzKGe8hVRvybevV46rVe4yUmk3WAvP=ux@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
	<AANLkTi=TQ=aUQOX9zLHCxh3XmvuFERfhs8qCYJHikBB=@mail.gmail.com>
	<op.vj4yvypaoiuain@smtp.mail.yahoo.com>
	<AANLkTik=M0ekzKGe8hVRvybevV46rVe4yUmk3WAvP=ux@mail.gmail.com>
Message-ID: <AANLkTimuvAzzt+szbh0dWMat5Bnyv2vgfuVqv48Rhwe8@mail.gmail.com>

I must agree with the "it's an unmitigated disaster" comments already
posted. But it does remind me of a C coding convention that was the
standard at a company worked at a long time ago. Here, the return
value from a function was always a coded int value where part of the
int told you the boolean pass/fail info, part encoded the severity,
part the product id, and part the specific message that could be
looked up to print. All packed into 32 bits. The analogy I can think
of is that you might want to return an instance of a standard class
instead of a raw tuple. It could have pass/fail info, perhaps more
extended info, plus a generic "payload" that would carry whatever the
function was really trying to return. This would at least save you
from interpreting ad hoc tuples everywhere, and might be a basis for
building something a bit more elegant.

-Andy

On Tue, Oct 5, 2010 at 9:16 PM, Nick S Kanakakorn <bbdada at gmail.com> wrote:
> I don't want to do this. ?There is someone that against throwing exception
> and that person has more seniority than me. He put in a guideline. ?I lost
> in the debate. ?There is no proper research done and all the decisions were
> made in less than 1 day.
>
> On Tue, Oct 5, 2010 at 9:03 PM, Tung Wai Yip <tungwaiyip at yahoo.com> wrote:
>>
>> Why do you want to do this? Is this just an internal coding guideline? Or
>> is it done for interfacing to another language or running on non-standard
>> VM? Is this apply to new code only or do you want to update existing code as
>> well?
>>
>> There is no equivalent of C macro in Python. Just apply every code change
>> as you describe it. Build a tuple every time you return something. Change
>> raise into returning tuple. And change ever function call to expecting a
>> tuple return value. I can't think of anything smarter. it looks like a
>> complete disaster anyway.
>>
>> Wai yip
>>
>>
>>
>>> Let's skip the rationale discussion although I feel better for your
>>> sympathy. ?One non python solution I can think of is Macro (C/C++) or add
>>> a
>>> new command ?which could work in any stack frame (TCL).
>>> However, I'm quite new to python so I'm not so sure if there are some
>>> ways
>>> around this.
>>>
>>> Can we have something similar to macro in python ?
>>>
>>> On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <glen at glenjarvis.com> wrote:
>>>
>>>>
>>>> > My work place has imposed a rules for no use of exception (catching is
>>>> allowed).
>>>>
>>>> What?!?
>>>>
>>>> Forgive my reaction, I'm just very surprised. Why has your workplace
>>>> implemented this policy? Has anyone else on BayPIGgies seen a ?policy
>>>> like
>>>> this? What's the rationale? ?Am I a Luddite for not hearing on this?
>>>>
>>>> I'm sorry. I know you asked a genuine question and I haven't answered
>>>> it. I
>>>> just found this very odd and am first getting my head around the
>>>> question.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>> Glen
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> http://mail.python.org/mailman/listinfo/baypiggies
>
>
>
> --
> -Nick Kanakakorn
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

From brent.tubbs at gmail.com  Wed Oct  6 06:43:57 2010
From: brent.tubbs at gmail.com (Brent Tubbs)
Date: Tue, 5 Oct 2010 21:43:57 -0700
Subject: [Baypiggies] YouGov looking for a Django contractor
Message-ID: <AANLkTi=FHeVT11us-ouBn_qeQOsC6d6h4QgNfG4-S1ti@mail.gmail.com>

My employer is looking for someone who knows Django to help on a
couple of projects for about a month.   (Though personally I wouldn't
be surprised if it was more like two months.)  The work is basically
taking a smallish Google App Engine app (in Python) and converting it
to run on regular Django, then improving it some.  If you're
comfortable with these technologies and interested in a short-term
gig, let me know off list.

Thanks!
Brent

(Oh and we're located in downtown Palo Alto.  You could work from our
office or from home.)

From bbdada at gmail.com  Wed Oct  6 07:32:22 2010
From: bbdada at gmail.com (Nick S Kanakakorn)
Date: Tue, 5 Oct 2010 22:32:22 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTimuvAzzt+szbh0dWMat5Bnyv2vgfuVqv48Rhwe8@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
	<AANLkTi=TQ=aUQOX9zLHCxh3XmvuFERfhs8qCYJHikBB=@mail.gmail.com>
	<op.vj4yvypaoiuain@smtp.mail.yahoo.com>
	<AANLkTik=M0ekzKGe8hVRvybevV46rVe4yUmk3WAvP=ux@mail.gmail.com>
	<AANLkTimuvAzzt+szbh0dWMat5Bnyv2vgfuVqv48Rhwe8@mail.gmail.com>
Message-ID: <AANLkTimQxJT4rkTg-b7MEapvj8X_UtyJ8ahzM4-OAfNw@mail.gmail.com>

Hi Andy,

Thanks for your comment.  I could wrap this in a class but I'm not so sure
how it would save me to have to do something like this.

class ReturnWrapper(object):
     def __init__(error_code, error_message, real_return_result)
           ....

def f1(arg):
    try
        x = some_function()
    except IndexError, e
        return ReturnWrapper(-1,'some error message' , None)
    # all good here
    return ReturnWrapper(0, None, 'some good value')

def f1caller()
    obj = f1(param1)
    if (obj.error_code < 0):
       # handle some error or just return obj
       return obj
    foo....
    obj = f1(param2)
    if (obj.error_code < 0):
       # handle some error or just return obj
       return obj
    bar....


I still have to use this pattern     if (obj.error_code < 0):  ....
It does not really make my code smaller than using tuple.
I used to code C similar to what you said I did not expect to have to do
the
same thing in python

Thanks,

On Tue, Oct 5, 2010 at 9:42 PM, Andy Wiggin <andywiggin at gmail.com> wrote:

> I must agree with the "it's an unmitigated disaster" comments already
> posted. But it does remind me of a C coding convention that was the
> standard at a company worked at a long time ago. Here, the return
> value from a function was always a coded int value where part of the
> int told you the boolean pass/fail info, part encoded the severity,
> part the product id, and part the specific message that could be
> looked up to print. All packed into 32 bits. The analogy I can think
> of is that you might want to return an instance of a standard class
> instead of a raw tuple. It could have pass/fail info, perhaps more
> extended info, plus a generic "payload" that would carry whatever the
> function was really trying to return. This would at least save you
> from interpreting ad hoc tuples everywhere, and might be a basis for
> building something a bit more elegant.
>
> -Andy
>
> On Tue, Oct 5, 2010 at 9:16 PM, Nick S Kanakakorn <bbdada at gmail.com>
> wrote:
> > I don't want to do this.  There is someone that against throwing
> exception
> > and that person has more seniority than me. He put in a guideline.  I
> lost
> > in the debate.  There is no proper research done and all the decisions
> were
> > made in less than 1 day.
> >
> > On Tue, Oct 5, 2010 at 9:03 PM, Tung Wai Yip <tungwaiyip at yahoo.com>
> wrote:
> >>
> >> Why do you want to do this? Is this just an internal coding guideline?
> Or
> >> is it done for interfacing to another language or running on
> non-standard
> >> VM? Is this apply to new code only or do you want to update existing
> code as
> >> well?
> >>
> >> There is no equivalent of C macro in Python. Just apply every code
> change
> >> as you describe it. Build a tuple every time you return something.
> Change
> >> raise into returning tuple. And change ever function call to expecting a
> >> tuple return value. I can't think of anything smarter. it looks like a
> >> complete disaster anyway.
> >>
> >> Wai yip
> >>
> >>
> >>
> >>> Let's skip the rationale discussion although I feel better for your
> >>> sympathy.  One non python solution I can think of is Macro (C/C++) or
> add
> >>> a
> >>> new command  which could work in any stack frame (TCL).
> >>> However, I'm quite new to python so I'm not so sure if there are some
> >>> ways
> >>> around this.
> >>>
> >>> Can we have something similar to macro in python ?
> >>>
> >>> On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <glen at glenjarvis.com>
> wrote:
> >>>
> >>>>
> >>>> > My work place has imposed a rules for no use of exception (catching
> is
> >>>> allowed).
> >>>>
> >>>> What?!?
> >>>>
> >>>> Forgive my reaction, I'm just very surprised. Why has your workplace
> >>>> implemented this policy? Has anyone else on BayPIGgies seen a  policy
> >>>> like
> >>>> this? What's the rationale?  Am I a Luddite for not hearing on this?
> >>>>
> >>>> I'm sorry. I know you asked a genuine question and I haven't answered
> >>>> it. I
> >>>> just found this very odd and am first getting my head around the
> >>>> question.
> >>>>
> >>>> Cheers,
> >>>>
> >>>>
> >>>> Glen
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> >> _______________________________________________
> >> Baypiggies mailing list
> >> Baypiggies at python.org
> >> To change your subscription options or unsubscribe:
> >> http://mail.python.org/mailman/listinfo/baypiggies
> >
> >
> >
> > --
> > -Nick Kanakakorn
> >
> > _______________________________________________
> > Baypiggies mailing list
> > Baypiggies at python.org
> > To change your subscription options or unsubscribe:
> > http://mail.python.org/mailman/listinfo/baypiggies
> >
>



-- 
-Nick Kanakakorn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101005/7ee0c270/attachment-0001.html>

From andywiggin at gmail.com  Wed Oct  6 08:33:13 2010
From: andywiggin at gmail.com (Andy Wiggin)
Date: Tue, 5 Oct 2010 23:33:13 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTimQxJT4rkTg-b7MEapvj8X_UtyJ8ahzM4-OAfNw@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
	<AANLkTi=TQ=aUQOX9zLHCxh3XmvuFERfhs8qCYJHikBB=@mail.gmail.com>
	<op.vj4yvypaoiuain@smtp.mail.yahoo.com>
	<AANLkTik=M0ekzKGe8hVRvybevV46rVe4yUmk3WAvP=ux@mail.gmail.com>
	<AANLkTimuvAzzt+szbh0dWMat5Bnyv2vgfuVqv48Rhwe8@mail.gmail.com>
	<AANLkTimQxJT4rkTg-b7MEapvj8X_UtyJ8ahzM4-OAfNw@mail.gmail.com>
Message-ID: <AANLkTintfCrcTEWj0_5nk+Ntei+R_u-bVGP5wcR4zDUn@mail.gmail.com>

Right. I couldn't get past that part either, at least based on what I
know about coding in pure python. When we did this in C of course we
used macros to wrap the standard return-on-error-of-child behavior and
every now and then wrote something more sophisticated (oh! Just like
an exception, except with extra text obscuring the code). So short of
using a macro-preprocessor to generate your python files, you can at
least standardize and condense the one-liner after each function call.
Here's what I came up with:


class FuncStatus:
    def __init__(self, success, payload):
        self.success = success
        self.payload = payload
    def err(self):
        return not self.success

def sub_test(v):
    if v > 0:
        return FuncStatus(True, "a b c")
    else:
        return FuncStatus(False, ["d", "e", "f"])

def main():
    #if (s = sub_test(-2)).err() return s
    s = sub_test(2)
    if s.err(): return s
    print "Hey 1", s.payload

    s = sub_test(-2)
    if s.err(): return s
    print "Hey 2", s.payload

main()

-Andy

On Tue, Oct 5, 2010 at 10:32 PM, Nick S Kanakakorn <bbdada at gmail.com> wrote:
> Hi Andy,
> Thanks for your comment. ?I could wrap this in a class but I'm not so sure
> how it would save me to have to do something like this.
> class ReturnWrapper(object):
> ?? ? def __init__(error_code, error_message, real_return_result)
> ?? ? ? ? ? ....
> def f1(arg):
> ?? ?try
> ?? ? ? ?x = some_function()
> ?? ?except IndexError, e
> ?? ? ? ?return ReturnWrapper(-1,'some error message' , None)
> ?? ?# all good here
> ?? ?return?ReturnWrapper(0, None, 'some good value')
> def f1caller()
> ?? ?obj = f1(param1)
> ?? ?if (obj.error_code < 0):
> ?? ? ? # handle some error or just return obj
> ?? ? ? return obj
> ?? ?foo....
> ?? ?obj = f1(param2)
> ?? ?if (obj.error_code < 0):
> ?? ? ? # handle some error or just return obj
> ?? ? ? return obj
> ?? ?bar....
>
> I still have to use this pattern??? ?if (obj.error_code < 0): ?....
> It does not really make my code smaller than using tuple.
> I used to code C similar to what you said I did not expect to have to do
> the
> same thing in python
> Thanks,
> On Tue, Oct 5, 2010 at 9:42 PM, Andy Wiggin <andywiggin at gmail.com> wrote:
>>
>> I must agree with the "it's an unmitigated disaster" comments already
>> posted. But it does remind me of a C coding convention that was the
>> standard at a company worked at a long time ago. Here, the return
>> value from a function was always a coded int value where part of the
>> int told you the boolean pass/fail info, part encoded the severity,
>> part the product id, and part the specific message that could be
>> looked up to print. All packed into 32 bits. The analogy I can think
>> of is that you might want to return an instance of a standard class
>> instead of a raw tuple. It could have pass/fail info, perhaps more
>> extended info, plus a generic "payload" that would carry whatever the
>> function was really trying to return. This would at least save you
>> from interpreting ad hoc tuples everywhere, and might be a basis for
>> building something a bit more elegant.
>>
>> -Andy
>>
>> On Tue, Oct 5, 2010 at 9:16 PM, Nick S Kanakakorn <bbdada at gmail.com>
>> wrote:
>> > I don't want to do this. ?There is someone that against throwing
>> > exception
>> > and that person has more seniority than me. He put in a guideline. ?I
>> > lost
>> > in the debate. ?There is no proper research done and all the decisions
>> > were
>> > made in less than 1 day.
>> >
>> > On Tue, Oct 5, 2010 at 9:03 PM, Tung Wai Yip <tungwaiyip at yahoo.com>
>> > wrote:
>> >>
>> >> Why do you want to do this? Is this just an internal coding guideline?
>> >> Or
>> >> is it done for interfacing to another language or running on
>> >> non-standard
>> >> VM? Is this apply to new code only or do you want to update existing
>> >> code as
>> >> well?
>> >>
>> >> There is no equivalent of C macro in Python. Just apply every code
>> >> change
>> >> as you describe it. Build a tuple every time you return something.
>> >> Change
>> >> raise into returning tuple. And change ever function call to expecting
>> >> a
>> >> tuple return value. I can't think of anything smarter. it looks like a
>> >> complete disaster anyway.
>> >>
>> >> Wai yip
>> >>
>> >>
>> >>
>> >>> Let's skip the rationale discussion although I feel better for your
>> >>> sympathy. ?One non python solution I can think of is Macro (C/C++) or
>> >>> add
>> >>> a
>> >>> new command ?which could work in any stack frame (TCL).
>> >>> However, I'm quite new to python so I'm not so sure if there are some
>> >>> ways
>> >>> around this.
>> >>>
>> >>> Can we have something similar to macro in python ?
>> >>>
>> >>> On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <glen at glenjarvis.com>
>> >>> wrote:
>> >>>
>> >>>>
>> >>>> > My work place has imposed a rules for no use of exception (catching
>> >>>> > is
>> >>>> allowed).
>> >>>>
>> >>>> What?!?
>> >>>>
>> >>>> Forgive my reaction, I'm just very surprised. Why has your workplace
>> >>>> implemented this policy? Has anyone else on BayPIGgies seen a ?policy
>> >>>> like
>> >>>> this? What's the rationale? ?Am I a Luddite for not hearing on this?
>> >>>>
>> >>>> I'm sorry. I know you asked a genuine question and I haven't answered
>> >>>> it. I
>> >>>> just found this very odd and am first getting my head around the
>> >>>> question.
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>>
>> >>>> Glen
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>> >> _______________________________________________
>> >> Baypiggies mailing list
>> >> Baypiggies at python.org
>> >> To change your subscription options or unsubscribe:
>> >> http://mail.python.org/mailman/listinfo/baypiggies
>> >
>> >
>> >
>> > --
>> > -Nick Kanakakorn
>> >
>> > _______________________________________________
>> > Baypiggies mailing list
>> > Baypiggies at python.org
>> > To change your subscription options or unsubscribe:
>> > http://mail.python.org/mailman/listinfo/baypiggies
>> >
>
>
>
> --
> -Nick Kanakakorn
>

From bbdada at gmail.com  Wed Oct  6 10:07:00 2010
From: bbdada at gmail.com (Nick S Kanakakorn)
Date: Wed, 6 Oct 2010 01:07:00 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTintfCrcTEWj0_5nk+Ntei+R_u-bVGP5wcR4zDUn@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<BABF2AF8-ECD0-4D36-AA51-99BE5C9673CD@glenjarvis.com>
	<AANLkTi=TQ=aUQOX9zLHCxh3XmvuFERfhs8qCYJHikBB=@mail.gmail.com>
	<op.vj4yvypaoiuain@smtp.mail.yahoo.com>
	<AANLkTik=M0ekzKGe8hVRvybevV46rVe4yUmk3WAvP=ux@mail.gmail.com>
	<AANLkTimuvAzzt+szbh0dWMat5Bnyv2vgfuVqv48Rhwe8@mail.gmail.com>
	<AANLkTimQxJT4rkTg-b7MEapvj8X_UtyJ8ahzM4-OAfNw@mail.gmail.com>
	<AANLkTintfCrcTEWj0_5nk+Ntei+R_u-bVGP5wcR4zDUn@mail.gmail.com>
Message-ID: <AANLkTimBGJZP5fRsbu4_SWNB9Somg9TYW-y=gwUNHKeL@mail.gmail.com>

Andy,

Thanks so much.

-Nick

On Tue, Oct 5, 2010 at 11:33 PM, Andy Wiggin <andywiggin at gmail.com> wrote:

> Right. I couldn't get past that part either, at least based on what I
> know about coding in pure python. When we did this in C of course we
> used macros to wrap the standard return-on-error-of-child behavior and
> every now and then wrote something more sophisticated (oh! Just like
> an exception, except with extra text obscuring the code). So short of
> using a macro-preprocessor to generate your python files, you can at
> least standardize and condense the one-liner after each function call.
> Here's what I came up with:
>
>
> class FuncStatus:
>    def __init__(self, success, payload):
>        self.success = success
>        self.payload = payload
>    def err(self):
>        return not self.success
>
> def sub_test(v):
>    if v > 0:
>        return FuncStatus(True, "a b c")
>    else:
>        return FuncStatus(False, ["d", "e", "f"])
>
> def main():
>    #if (s = sub_test(-2)).err() return s
>    s = sub_test(2)
>    if s.err(): return s
>    print "Hey 1", s.payload
>
>    s = sub_test(-2)
>    if s.err(): return s
>    print "Hey 2", s.payload
>
> main()
>
> -Andy
>
> On Tue, Oct 5, 2010 at 10:32 PM, Nick S Kanakakorn <bbdada at gmail.com>
> wrote:
> > Hi Andy,
> > Thanks for your comment.  I could wrap this in a class but I'm not so
> sure
> > how it would save me to have to do something like this.
> > class ReturnWrapper(object):
> >      def __init__(error_code, error_message, real_return_result)
> >            ....
> > def f1(arg):
> >     try
> >         x = some_function()
> >     except IndexError, e
> >         return ReturnWrapper(-1,'some error message' , None)
> >     # all good here
> >     return ReturnWrapper(0, None, 'some good value')
> > def f1caller()
> >     obj = f1(param1)
> >     if (obj.error_code < 0):
> >        # handle some error or just return obj
> >        return obj
> >     foo....
> >     obj = f1(param2)
> >     if (obj.error_code < 0):
> >        # handle some error or just return obj
> >        return obj
> >     bar....
> >
> > I still have to use this pattern     if (obj.error_code < 0):  ....
> > It does not really make my code smaller than using tuple.
> > I used to code C similar to what you said I did not expect to have to do
> > the
> > same thing in python
> > Thanks,
> > On Tue, Oct 5, 2010 at 9:42 PM, Andy Wiggin <andywiggin at gmail.com>
> wrote:
> >>
> >> I must agree with the "it's an unmitigated disaster" comments already
> >> posted. But it does remind me of a C coding convention that was the
> >> standard at a company worked at a long time ago. Here, the return
> >> value from a function was always a coded int value where part of the
> >> int told you the boolean pass/fail info, part encoded the severity,
> >> part the product id, and part the specific message that could be
> >> looked up to print. All packed into 32 bits. The analogy I can think
> >> of is that you might want to return an instance of a standard class
> >> instead of a raw tuple. It could have pass/fail info, perhaps more
> >> extended info, plus a generic "payload" that would carry whatever the
> >> function was really trying to return. This would at least save you
> >> from interpreting ad hoc tuples everywhere, and might be a basis for
> >> building something a bit more elegant.
> >>
> >> -Andy
> >>
> >> On Tue, Oct 5, 2010 at 9:16 PM, Nick S Kanakakorn <bbdada at gmail.com>
> >> wrote:
> >> > I don't want to do this.  There is someone that against throwing
> >> > exception
> >> > and that person has more seniority than me. He put in a guideline.  I
> >> > lost
> >> > in the debate.  There is no proper research done and all the decisions
> >> > were
> >> > made in less than 1 day.
> >> >
> >> > On Tue, Oct 5, 2010 at 9:03 PM, Tung Wai Yip <tungwaiyip at yahoo.com>
> >> > wrote:
> >> >>
> >> >> Why do you want to do this? Is this just an internal coding
> guideline?
> >> >> Or
> >> >> is it done for interfacing to another language or running on
> >> >> non-standard
> >> >> VM? Is this apply to new code only or do you want to update existing
> >> >> code as
> >> >> well?
> >> >>
> >> >> There is no equivalent of C macro in Python. Just apply every code
> >> >> change
> >> >> as you describe it. Build a tuple every time you return something.
> >> >> Change
> >> >> raise into returning tuple. And change ever function call to
> expecting
> >> >> a
> >> >> tuple return value. I can't think of anything smarter. it looks like
> a
> >> >> complete disaster anyway.
> >> >>
> >> >> Wai yip
> >> >>
> >> >>
> >> >>
> >> >>> Let's skip the rationale discussion although I feel better for your
> >> >>> sympathy.  One non python solution I can think of is Macro (C/C++)
> or
> >> >>> add
> >> >>> a
> >> >>> new command  which could work in any stack frame (TCL).
> >> >>> However, I'm quite new to python so I'm not so sure if there are
> some
> >> >>> ways
> >> >>> around this.
> >> >>>
> >> >>> Can we have something similar to macro in python ?
> >> >>>
> >> >>> On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <glen at glenjarvis.com>
> >> >>> wrote:
> >> >>>
> >> >>>>
> >> >>>> > My work place has imposed a rules for no use of exception
> (catching
> >> >>>> > is
> >> >>>> allowed).
> >> >>>>
> >> >>>> What?!?
> >> >>>>
> >> >>>> Forgive my reaction, I'm just very surprised. Why has your
> workplace
> >> >>>> implemented this policy? Has anyone else on BayPIGgies seen a
>  policy
> >> >>>> like
> >> >>>> this? What's the rationale?  Am I a Luddite for not hearing on
> this?
> >> >>>>
> >> >>>> I'm sorry. I know you asked a genuine question and I haven't
> answered
> >> >>>> it. I
> >> >>>> just found this very odd and am first getting my head around the
> >> >>>> question.
> >> >>>>
> >> >>>> Cheers,
> >> >>>>
> >> >>>>
> >> >>>> Glen
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Using Opera's revolutionary e-mail client:
> http://www.opera.com/mail/
> >> >> _______________________________________________
> >> >> Baypiggies mailing list
> >> >> Baypiggies at python.org
> >> >> To change your subscription options or unsubscribe:
> >> >> http://mail.python.org/mailman/listinfo/baypiggies
> >> >
> >> >
> >> >
> >> > --
> >> > -Nick Kanakakorn
> >> >
> >> > _______________________________________________
> >> > Baypiggies mailing list
> >> > Baypiggies at python.org
> >> > To change your subscription options or unsubscribe:
> >> > http://mail.python.org/mailman/listinfo/baypiggies
> >> >
> >
> >
> >
> > --
> > -Nick Kanakakorn
> >
>



-- 
-Nick Kanakakorn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101006/86cb64b8/attachment-0001.html>

From dalke at dalkescientific.com  Wed Oct  6 17:01:41 2010
From: dalke at dalkescientific.com (Andrew Dalke)
Date: Wed, 6 Oct 2010 09:01:41 -0600
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTi=jKHF9zHaPG=1SZngW+w=kSW8o9QxMcM16rm3z@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<AANLkTi=jKHF9zHaPG=1SZngW+w=kSW8o9QxMcM16rm3z@mail.gmail.com>
Message-ID: <918DB0BF-8806-430E-92F6-CEE14A0FC1E7@dalkescientific.com>

On Oct 5, 2010, at 9:57 PM, James Tatum wrote:
> I've seen this anti-pattern up close. There is no Pythonic answer -
> exceptions are the answer.

There is a Pythonic answer - you can go the Twisted route.
(Excepting those who think Twisted isn't Pythonic. ;)

Twisted's Deferreds can't use the stack because they
implement continuations through callback methods. You
"addCallback" for the normal case and "addErrback" for the
exceptions.

It's possible to develop your entire code base this way.

It's going to be structured entirely different than what
the OP's more senior rule mandator expects, but that might
be a good thing here.


				Andrew
				dalke at dalkescientific.com



From mparker at energy-solution.com  Wed Oct  6 18:30:00 2010
From: mparker at energy-solution.com (Marla Parker)
Date: Wed, 6 Oct 2010 16:30:00 +0000
Subject: [Baypiggies] Graham Dumpleton mod_wsgi talk Oct 8, 7:30
Message-ID: <6F83CE1A-AD00-4315-B805-73C90E1080DA@energy-solution.com>


Please join us Friday evening!

Graham Dumpleton is here on a family vacation but hopes to spend a few hours with
the local python community at Noisebridge in San Francisco,
located on the 3rd floor of 2169 Mission Street, San Francisco, CA 94110-1219<http://maps.google.com/?q=2169+Mission+Street,+94110>.

"""Getting to know mod_wsgi."""

"""Graham will describe the architecture of mod_wsgi and how that
compares to other Python hosting solutions. He will then discuss the
pros and cons of the different modes mod_wsgi supports for running
WSGI applications. Question time will follow, allowing for a more
in-depth discussion of the material covered or anything else people
want to know about mod_wsgi."""

The link to the announcement on the noisebridge site is here:
https://www.noisebridge.net/wiki/Category:Events#Upcoming_Events_edit

Energy Solutions is taking Graham to dinner before the talk at http://www.pocchuc.com/
nearby.  I've not been there but I called and they said they are big enough to absorb
a bunch of drop-ins, so if others want to arrange to meet there for dinner before
the talk, please make your own connections and be ready to pay for your dinner.
Sorry ES cannot host dinner for everyone.  :)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101006/d927cace/attachment.html>

From glen at glenjarvis.com  Wed Oct  6 19:28:31 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Wed, 6 Oct 2010 10:28:31 -0700
Subject: [Baypiggies] Join me Sat and Sun?
Message-ID: <AANLkTikjGu+4=u-=Kp1P1basmotvLWqXiuzhENadgKeP@mail.gmail.com>

I'm taking this track at the Silicon Valley Code Camp (I decided not to
present after all):


9:45 Sat   Introducing Google APIs Part I (A-Z and Geo)
11:15 Sat Introducing Google APIs Part II (Apps)
1:45 Sat Introducing Google APIs Part III (New and Exciting)
3:30 Sat An introduction to Google Web Toolkit and Ext GWT
5:00 Sat Google Chrome/HTML 5

9:15 Sun Fun with HTML5, CSS3, and JavaScript
10:45 Sun Mobile HTML 5.0
1:15 Sun Building Video Applications with YouTube APIs
2:45 Sun How to take your current Javascript/PHP app and make it scale


Anyone going to these sessions? Wanna hang out?

If you haven't signed up yet, here's the URL:
http://www.siliconvalley-codecamp.com/

See you Saturday and Sunday....


Cheers,


Glen
P.S. This is actually python related, but peripherally..
-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101006/9fbcceea/attachment.html>

From daniel at djansoft.com  Wed Oct  6 19:51:32 2010
From: daniel at djansoft.com (=?ISO-8859-1?Q?Daniel_Gonz=E1lez_Gasull?=)
Date: Wed, 6 Oct 2010 10:51:32 -0700
Subject: [Baypiggies] Join me Sat and Sun?
In-Reply-To: <AANLkTikjGu+4=u-=Kp1P1basmotvLWqXiuzhENadgKeP@mail.gmail.com>
References: <AANLkTikjGu+4=u-=Kp1P1basmotvLWqXiuzhENadgKeP@mail.gmail.com>
Message-ID: <AANLkTimCzz=Who75McUmwyxzLTFdEp+tZ+zgL=XSff8s@mail.gmail.com>

There's an introductory class to Python and another one to Google App Engine:

http://www.siliconvalley-codecamp.com/SessionsOverview.aspx

I'm going to the Mobile HTML 5 class too.  See you there.


On Wed, Oct 6, 2010 at 10:28 AM, Glen Jarvis <glen at glenjarvis.com> wrote:
> I'm taking this track at the Silicon Valley Code Camp (I decided not to
> present after all):
>
> 9:45 Sat ? Introducing Google APIs Part I (A-Z and Geo)
> 11:15 Sat Introducing Google APIs Part II (Apps)
> 1:45 Sat Introducing Google APIs Part III (New and Exciting)
> 3:30 Sat An introduction to Google Web Toolkit and Ext GWT
> 5:00 Sat Google Chrome/HTML 5
> 9:15 Sun Fun with HTML5, CSS3, and JavaScript
> 10:45 Sun Mobile HTML 5.0
> 1:15 Sun Building Video Applications with YouTube APIs
> 2:45 Sun How to take your current Javascript/PHP app and make it scale
>
> Anyone going to these sessions? Wanna hang out?
> If you haven't signed up yet, here's the URL:
> http://www.siliconvalley-codecamp.com/
> See you Saturday and Sunday....
>
> Cheers,
>
> Glen
> P.S. This is actually python related, but peripherally..
> --
> Whatever you can do or imagine, begin it;
> boldness has beauty, magic, and power in it.
>
> -- Goethe
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>



-- 
http://DjanSoft.com :: Agile Application Development with Python

From venkat83 at gmail.com  Wed Oct  6 20:17:10 2010
From: venkat83 at gmail.com (Venkatraman S)
Date: Wed, 6 Oct 2010 23:47:10 +0530
Subject: [Baypiggies] Constructing XML
Message-ID: <AANLkTikjKn0WDTh8zVtK1U1xAPz-jbPBkg-=cF6T5HRb@mail.gmail.com>

Hi,

I was wondering whether there is a better way (or an elegant 'pattern') to
construct an xml document. Lets say I have many variables(can be lists,
dicts, strings etc) and the corresponding values, so some tags have just one
text value whereas some have siblings etc and also have their respective
attributes. Is it possible to construct the XML just based on this structure
of variables.

I am not sure whether I am framing my Q right, but let me explain it with an
example:
strtag="Hello World"
listtag = [10,20,30]
dicttag={'a':100,'b':200}

And when the above variables are fed into a black box, i get the output xml:
<strtag>Hello World</strtag>
<listtag>10</listtag>
<listtag>20</listtag>
<listtag>30</listtag>
<dicttag>
  <a> 100</a>
  <b> 200</b>
</dicttag>

The above example 'again' might not make sense exactly in terms of how the
black box deciphers how the xml hierarchy can be maintained; I am looking
for a better example !!

-V-
http://twitter.com/venkasub
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101006/c2154bb8/attachment.html>

From daniel at djansoft.com  Wed Oct  6 20:32:54 2010
From: daniel at djansoft.com (=?ISO-8859-1?Q?Daniel_Gonz=E1lez_Gasull?=)
Date: Wed, 6 Oct 2010 11:32:54 -0700
Subject: [Baypiggies] Constructing XML
In-Reply-To: <AANLkTikjKn0WDTh8zVtK1U1xAPz-jbPBkg-=cF6T5HRb@mail.gmail.com>
References: <AANLkTikjKn0WDTh8zVtK1U1xAPz-jbPBkg-=cF6T5HRb@mail.gmail.com>
Message-ID: <AANLkTink6e5hizY6TdYg+PekUNdciKGFNXfZADrahrQ-@mail.gmail.com>

I haven't used it much, but I like PyQuery: http://pypi.python.org/pypi/pyquery

Also, avoid XML at all if you can and use JSON instead or some other
format.  It will save you a few headaches.

On Wed, Oct 6, 2010 at 11:17 AM, Venkatraman S <venkat83 at gmail.com> wrote:
> Hi,
>
> I was wondering whether there is a better way (or an elegant 'pattern') to
> construct an xml document. Lets say I have many variables(can be lists,
> dicts, strings etc) and the corresponding values, so some tags have just one
> text value whereas some have siblings etc and also have their respective
> attributes. Is it possible to construct the XML just based on this structure
> of variables.
>
> I am not sure whether I am framing my Q right, but let me explain it with an
> example:
> strtag="Hello World"
> listtag = [10,20,30]
> dicttag={'a':100,'b':200}
>
> And when the above variables are fed into a black box, i get the output xml:
> <strtag>Hello World</strtag>
> <listtag>10</listtag>
> <listtag>20</listtag>
> <listtag>30</listtag>
> <dicttag>
> ? <a> 100</a>
> ? <b> 200</b>
> </dicttag>
>
> The above example 'again' might not make sense exactly in terms of how the
> black box deciphers how the xml hierarchy can be maintained; I am looking
> for a better example !!
>
> -V-
> http://twitter.com/venkasub
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>



-- 
http://DjanSoft.com :: Agile Application Development with Python

From keith at dartworks.biz  Wed Oct  6 21:37:42 2010
From: keith at dartworks.biz (Keith Dart)
Date: Wed, 6 Oct 2010 12:37:42 -0700
Subject: [Baypiggies] Constructing XML
In-Reply-To: <AANLkTikjKn0WDTh8zVtK1U1xAPz-jbPBkg-=cF6T5HRb@mail.gmail.com>
References: <AANLkTikjKn0WDTh8zVtK1U1xAPz-jbPBkg-=cF6T5HRb@mail.gmail.com>
Message-ID: <20101006123742.1c7b2818@dartworks.biz>

=== On Wed, 10/06, Venkatraman S wrote: ===
> strtag="Hello World"
> listtag = [10,20,30]
> dicttag={'a':100,'b':200}
> 
> And when the above variables are fed into a black box, i get the
> output xml: <strtag>Hello World</strtag>

===

It looks like you want XML serialized objects. You might be interested
in this recipe:

http://code.activestate.com/recipes/355487-pickle-python-objects-to-a-dom-tree-and-vice-versa/

Try googling for XML serialized objects. I think there are more.


-- Keith Dart

-- 
-- ------------------------------
Keith Dart
=================================


From hotelsamurai at gmail.com  Thu Oct  7 06:45:41 2010
From: hotelsamurai at gmail.com (Shirt Guy)
Date: Wed, 6 Oct 2010 21:45:41 -0700
Subject: [Baypiggies] Join me Sat and Sun?
In-Reply-To: <AANLkTikjGu+4=u-=Kp1P1basmotvLWqXiuzhENadgKeP@mail.gmail.com>
References: <AANLkTikjGu+4=u-=Kp1P1basmotvLWqXiuzhENadgKeP@mail.gmail.com>
Message-ID: <AANLkTi=mZcA7m7+kJTFva0F25DZsuAMQmzzuUG6SkVE4@mail.gmail.com>

I'll be there at least for the Google API modules, would love to meet up.

On 10/6/10, Glen Jarvis <glen at glenjarvis.com> wrote:
> I'm taking this track at the Silicon Valley Code Camp (I decided not to
> present after all):
>
>
> 9:45 Sat   Introducing Google APIs Part I (A-Z and Geo)
> 11:15 Sat Introducing Google APIs Part II (Apps)
> 1:45 Sat Introducing Google APIs Part III (New and Exciting)
> 3:30 Sat An introduction to Google Web Toolkit and Ext GWT
> 5:00 Sat Google Chrome/HTML 5
>
> 9:15 Sun Fun with HTML5, CSS3, and JavaScript
> 10:45 Sun Mobile HTML 5.0
> 1:15 Sun Building Video Applications with YouTube APIs
> 2:45 Sun How to take your current Javascript/PHP app and make it scale
>
>
> Anyone going to these sessions? Wanna hang out?
>
> If you haven't signed up yet, here's the URL:
> http://www.siliconvalley-codecamp.com/
>
> See you Saturday and Sunday....
>
>
> Cheers,
>
>
> Glen
> P.S. This is actually python related, but peripherally..
> --
> Whatever you can do or imagine, begin it;
> boldness has beauty, magic, and power in it.
>
> -- Goethe
>

From brent.tubbs at gmail.com  Wed Oct  6 23:02:54 2010
From: brent.tubbs at gmail.com (Brent Tubbs)
Date: Wed, 6 Oct 2010 14:02:54 -0700
Subject: [Baypiggies] Join me Sat and Sun?
In-Reply-To: <AANLkTimCzz=Who75McUmwyxzLTFdEp+tZ+zgL=XSff8s@mail.gmail.com>
References: <AANLkTikjGu+4=u-=Kp1P1basmotvLWqXiuzhENadgKeP@mail.gmail.com>
	<AANLkTimCzz=Who75McUmwyxzLTFdEp+tZ+zgL=XSff8s@mail.gmail.com>
Message-ID: <AANLkTi=xiOgU+OBC6b+xnjAJOPL9SySyKKKcvvY+=dWk@mail.gmail.com>

I'm planning to be in the 1:45 Google APIs class, but doing Android
stuff in the morning.

Brent

2010/10/6 Daniel Gonz?lez Gasull <daniel at djansoft.com>:
> There's an introductory class to Python and another one to Google App Engine:
>
> http://www.siliconvalley-codecamp.com/SessionsOverview.aspx
>
> I'm going to the Mobile HTML 5 class too. ?See you there.
>
>
> On Wed, Oct 6, 2010 at 10:28 AM, Glen Jarvis <glen at glenjarvis.com> wrote:
>> I'm taking this track at the Silicon Valley Code Camp (I decided not to
>> present after all):
>>
>> 9:45 Sat ? Introducing Google APIs Part I (A-Z and Geo)
>> 11:15 Sat Introducing Google APIs Part II (Apps)
>> 1:45 Sat Introducing Google APIs Part III (New and Exciting)
>> 3:30 Sat An introduction to Google Web Toolkit and Ext GWT
>> 5:00 Sat Google Chrome/HTML 5
>> 9:15 Sun Fun with HTML5, CSS3, and JavaScript
>> 10:45 Sun Mobile HTML 5.0
>> 1:15 Sun Building Video Applications with YouTube APIs
>> 2:45 Sun How to take your current Javascript/PHP app and make it scale
>>
>> Anyone going to these sessions? Wanna hang out?
>> If you haven't signed up yet, here's the URL:
>> http://www.siliconvalley-codecamp.com/
>> See you Saturday and Sunday....
>>
>> Cheers,
>>
>> Glen
>> P.S. This is actually python related, but peripherally..
>> --
>> Whatever you can do or imagine, begin it;
>> boldness has beauty, magic, and power in it.
>>
>> -- Goethe
>>
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> http://mail.python.org/mailman/listinfo/baypiggies
>>
>
>
>
> --
> http://DjanSoft.com :: Agile Application Development with Python
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

From jjinux at gmail.com  Thu Oct  7 04:40:14 2010
From: jjinux at gmail.com (Shannon -jj Behrens)
Date: Wed, 6 Oct 2010 19:40:14 -0700
Subject: [Baypiggies] Constructing XML
In-Reply-To: <20101006123742.1c7b2818@dartworks.biz>
References: <AANLkTikjKn0WDTh8zVtK1U1xAPz-jbPBkg-=cF6T5HRb@mail.gmail.com>
	<20101006123742.1c7b2818@dartworks.biz>
Message-ID: <AANLkTimHJrJfyoZNwKi=7kztaawXgZo6O+ErxP4KLZzp@mail.gmail.com>

You might want to check out Stan (part of Nevow) or Genshi.  I'm not
promising either will do exactly what you want, but it's a start.
Generally, when I want pure serialization, I use JSON.

-jj

On Wed, Oct 6, 2010 at 12:37 PM, Keith Dart <keith at dartworks.biz> wrote:
> === On Wed, 10/06, Venkatraman S wrote: ===
>> strtag="Hello World"
>> listtag = [10,20,30]
>> dicttag={'a':100,'b':200}
>>
>> And when the above variables are fed into a black box, i get the
>> output xml: <strtag>Hello World</strtag>
>
> ===
>
> It looks like you want XML serialized objects. You might be interested
> in this recipe:
>
> http://code.activestate.com/recipes/355487-pickle-python-objects-to-a-dom-tree-and-vice-versa/
>
> Try googling for XML serialized objects. I think there are more.
>
>
> -- Keith Dart
>
> --
> -- ------------------------------
> Keith Dart
> =================================
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>



-- 
In this life we cannot do great things. We can only do small things
with great love. -- Mother Teresa
http://jjinux.blogspot.com/

From brent.tubbs at gmail.com  Wed Oct  6 23:28:43 2010
From: brent.tubbs at gmail.com (Brent Tubbs)
Date: Wed, 6 Oct 2010 14:28:43 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <918DB0BF-8806-430E-92F6-CEE14A0FC1E7@dalkescientific.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<AANLkTi=jKHF9zHaPG=1SZngW+w=kSW8o9QxMcM16rm3z@mail.gmail.com>
	<918DB0BF-8806-430E-92F6-CEE14A0FC1E7@dalkescientific.com>
Message-ID: <AANLkTin-9HXd-i0W1w2hCayTvodyZiLf5JYS8_JnwY3i@mail.gmail.com>

Nick: Is your boss likely to notice something like this?

(except.py)
class TotallyNotAnExceptionNothingToSeeHere(Exception):
    pass

raise TotallyNotAnExceptionNothingToSeeHere("Really, pay me no attention")

brent at greta:~/tmp$ python except.py
Traceback (most recent call last):
  File "except.py", line 4, in <module>
    raise TotallyNotAnExceptionNothingToSeeHere("Really, pay me no attention")
__main__.TotallyNotAnExceptionNothingToSeeHere: Really, pay me no attention

Kidding.... mostly.  The "no exceptions" rule just seems really arbitrary.

Brent

On Wed, Oct 6, 2010 at 8:01 AM, Andrew Dalke <dalke at dalkescientific.com> wrote:
> On Oct 5, 2010, at 9:57 PM, James Tatum wrote:
>> I've seen this anti-pattern up close. There is no Pythonic answer -
>> exceptions are the answer.
>
> There is a Pythonic answer - you can go the Twisted route.
> (Excepting those who think Twisted isn't Pythonic. ;)
>
> Twisted's Deferreds can't use the stack because they
> implement continuations through callback methods. You
> "addCallback" for the normal case and "addErrback" for the
> exceptions.
>
> It's possible to develop your entire code base this way.
>
> It's going to be structured entirely different than what
> the OP's more senior rule mandator expects, but that might
> be a good thing here.
>
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Andrew
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dalke at dalkescientific.com
>
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

From marissa at imo.im  Thu Oct  7 02:56:09 2010
From: marissa at imo.im (Marissa Huang)
Date: Wed, 6 Oct 2010 17:56:09 -0700
Subject: [Baypiggies] server donation to local nonprofit 501c3 corporation
Message-ID: <AANLkTikQEf8B3LLrki8DK-eh2f0hxuSYNVci69StsOPp@mail.gmail.com>

I work for imo (https://imo.im/), a small startup in Palo Alto, CA.
We have a number of working rackform rackmount servers mostly dual
core (with some quad core) that we would like to donate to a local
nonprofit 501c3 corporation that would be able to pick them up.  We
are going to remove the drives, but I have included a list of some of
the specs.  If anyone is involved in an organization that would find
good use for them, please email me: marissa at imo.im.

Thanks!

--Marissa

-- 
https://chrome.google.com/extensions/detail/jefcommcgcjfonaaclmhmkefbngjdnlk

http://thenextweb.com/apps/2010/04/16/instant-messaging-twitter-reality/



15 Rackform iServ R121

CPU: Intel Xeon X3220 2.40GHz Quad-Core - 8MB L2 Smart Cache 1066MHz System Bus

RAM: 2GB (2 x 1GB) Unbuffered ECC DDR2-667

NIC: Dual 10/100/1000 Mbps NICs (Intel 82573L + 82573V) - Integrated

Management: No Item Selected

PCI Riser Options: PCIe (For PCI-X Options, Please Contact our Sales
Department)

PCIe x8: No Item Selected

Hot-Swap Drive - 1: 250GB Western Digital RE (3.0Gb/s, 7.2Krpm, 16MB
Cache) SATA (REMOVED)

Optical Drive: No Item Selected

Floppy Drive: No Item Selected

Rail Kit: 2 Piece Ball Bearing Rail Kit

OS: No Item Selected

Warranty: Standard 3 Year - Return to Depot - Advanced Component Exchange

Notes: No OS, No RAID

Configured Power: 201 Watts, 206 Volt-Amps, 686 BTU/h, 1.9 Amps

(110V), 1.0 Amps (208V)

Serial Numbers: SM39826, SM39827, SM39828, SM39829, SM39830, SM39831,

SM39832, SM39833, SM39834, SM39835, SM39836, SM39837, SM39838,

SM39839, SM39840




9 Rackform iServ R121

CPU: Intel Xeon 3060 2.40GHz Dual Core - 4MB Cache 1066MHz System Bus

RAM: 2GB (2 x 1GB) Unbuffered ECC DDR2-667

NIC: Dual 10/100/1000 Mbps NICs (Intel 82573L + 82573V) - Integrated

Management: None

PCI Riser Options: PCIe (For PCI-X Options, Please Contact our Sales
Department)

PCI: None

Hot-Swap HDD 1: Western Digital RE 250GB (3.0Gb/s, 7.2Krpm, 16MB
Cache) SATA (REMOVED)

Optical Media Drive: None

Floppy: None

Rail Kit: 2 Piece Ball Bearing Rail Kit

O/S: None

WARRANTY: Standard 3 Year - Return to Depot - Advanced Component Exchange

Serial Numbers: SM28949, SM28950, SM28951, SM28953, SM28954, SM28955,

SM28956, SM28957, SM28958




Tracking Number: 1Z9Y393Y0365569961

1 Rackform iServ R121

CPU: Intel Xeon 3060 2.40GHz Dual Core - 4MB Cache 1066MHz System Bus

RAM: 2GB (2 x 1GB) Unbuffered ECC DDR2-667

NIC: Dual 10/100/1000 Mbps NICs (Intel 82573L + 82573V) - Integrated

Management: None

PCI Riser Options: PCIe (For PCI-X Options, Please Contact our Sales
Department)

PCI: None

Hot-Swap HDD 1: Western Digital RE 250GB (3.0Gb/s, 7.2Krpm, 16MB Cache) SATA

Optical Media Drive: None

Floppy: None

Rail Kit: 2 Piece Ball Bearing Rail Kit

O/S: None

WARRANTY: Standard 3 Year - Return to Depot - Advanced Component Exchange



5 Rackform iServ R102 "Servers"

CPU: Intel Pentium D 920 (2.8GHz, Dual Core, 2MB/Core L2 Cache, EM64T, 800 FSB)

RAM: 2GB (2 x 1GB) Unbuffered ECC DDR2-667

NIC: Dual 10/100/1000 Mbps NICs (Intel 82573V) - Integrated

Management: None

PCI-X - 64Bit/133MHz: None

Hot-Swap HDD 1: Western Digital RE 250GB (1.5Gb/s, 7.2Krpm, 16MB
Cache) SATA (REMOVED)

Hot-Swap HDD 2: Western Digital RE 250GB (1.5Gb/s, 7.2Krpm, 16MB
Cache) SATA (REMOVED)

Optical Media Drive: None

Floppy: None

Rail Kit: 2 Piece Ball Bearing Rail Kit

O/S: None

WARRANTY: Standard 3 Year - Return to Depot

NOTES: HD: JBOD

Serial Numbers: SM19934, SM19935, SM19936, SM19937, SM19938


3 Rackform iServ R102

CPU: Intel Pentium D 820 (2.8GHz, Dual Core, 1MB/Core L2 Cache, EM64T, 800 FSB)

RAM: 2GB (2 x 1GB) Unbuffered ECC DDR2-667

NIC: Dual 10/100/1000 Mbps NICs (Intel 82573V) - Integrated

Management: None

PCI-X - 64Bit/133MHz: None

Hot-Swap HDD 1: Western Digital RE 250GB (1.5Gb/s, 7.2Krpm, 8MB Cache)
SATA (REMOVED)

Hot-Swap HDD 2: Western Digital RE 250GB (1.5Gb/s, 7.2Krpm, 8MB Cache)
SATA (REMOVED)

Optical Media Drive: None

Floppy: None

Rail Kit: 2 Piece Ball Bearing Rail Kit

O/S: None

WARRANTY: Standard 3 Year - Return to Depot

Serial Numbers: SM19577, SM19578, SM19579



3 Rackform iServ R102

CPU: Intel Pentium D 820 (2.8GHz) 2MB L2 Cache - HT - 800 FSB LGA775

EM64T Dual Core

RAM: 2GB (2 x 1GB) Unbuffered non-ECC DDR2-533

NIC: Dual 10/100/1000 Mbps NICs (Intel 82573V) - Integrated

PCI-X - 64Bit/133MHz: None

Hot-Swap HDD 1: Western Digital RE 250GB (7.2Krpm-8MB Cache) SATA (REMOVED)

Hot-Swap HDD 2: Western Digital RE 250GB (7.2Krpm-8MB Cache) SATA (REMOVED)

Low Profile CD-ROM: None

Floppy: None

Rail Kit: 2 Piece Ball Bearing Rail Kit

O/S: None

WARRANTY: Standard 3 Year - Return to Depot

Serial Numbers: SM18038, SM18039, SM18040

From daniel at djansoft.com  Thu Oct  7 01:22:28 2010
From: daniel at djansoft.com (=?ISO-8859-1?Q?Daniel_Gonz=E1lez_Gasull?=)
Date: Wed, 6 Oct 2010 16:22:28 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTik=6gYQAa6gB7cLycq9KJ4GhZ3O7QMMrVa5vmXJ@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<AANLkTik=6gYQAa6gB7cLycq9KJ4GhZ3O7QMMrVa5vmXJ@mail.gmail.com>
Message-ID: <AANLkTikJR4yc9bMjeyr1+nbHMz-+JygPFhOJ7MgcGtOd@mail.gmail.com>

On Sat, Oct 2, 2010 at 9:53 AM, Luca Pellicoro <luca.pellicoro at gmail.com> wrote:
> Just ran into Pexpect a few minutes ago. Is this what you're looking for?
> http://www.noah.org/wiki/Pexpect#Overview

Thank you for sharing this.

I wonder if there is something similar for the X Window System.  I use GNOME.

-- 
http://DjanSoft.com :: Agile Application Development with Python

From bbdada at gmail.com  Wed Oct  6 23:50:52 2010
From: bbdada at gmail.com (Nick S Kanakakorn)
Date: Wed, 6 Oct 2010 14:50:52 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
Message-ID: <AANLkTi=HFTxxD=7KJT5zaSnGf5k_jC+0r-QcKaU3cTWZ@mail.gmail.com>

There is a happy news here today.  The use of raise exception is allowed
again after I put some coding in using this convention:

exitcode, actual_result = f1()
if exitcode < 0: return exitcode
.... continue something useful with actual_result
exitcode, actual_result = f1()



On Tue, Oct 5, 2010 at 7:15 PM, Nick S Kanakakorn <bbdada at gmail.com> wrote:

> Hi,
>
> My work place has imposed a rules for no use of exception (catching is
> allowed).  If I have code like this
>
> def f1()
>   if bad_thing_happen():
>      raise Exception('bad stuff')
>   ...
>   return something
>
> I could change it to
>
> def f1()
>   if bad_thing_happen():
>     return [-1, None]
>   ...
>   return [0, something]
>
> f1 caller would be like this
>
> def f1_caller():
>   code, result = f1(param1)
>   if code < 0:
>     return code
>   actual_work1()
>   # call f1 again
>   code, result = f1(param2)
>   if code < 0:
>     return code
>   actual_work2()
>   ...
>
> Are there more elegant ways than this in Python ?
>
> Thanks,
> Nick K
>
>


-- 
-Nick Kanakakorn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101006/1314abb7/attachment.html>

From Todd_DeLuca at hms.harvard.edu  Thu Oct  7 02:34:54 2010
From: Todd_DeLuca at hms.harvard.edu (DeLuca, Todd)
Date: Wed, 6 Oct 2010 20:34:54 -0400
Subject: [Baypiggies] Python way to avoid usage of raise
Message-ID: <7095A0FC-6985-43D2-A9D4-B9EDA9EFA48D@hms.harvard.edu>

You could raise some exceptions without the word 'raise'.

>>> 'a' + 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects


Todd DeLuca

From jtatum at gmail.com  Thu Oct  7 18:03:21 2010
From: jtatum at gmail.com (James Tatum)
Date: Thu, 7 Oct 2010 09:03:21 -0700
Subject: [Baypiggies] Subprocess: Common problem/common pattern
In-Reply-To: <AANLkTikJR4yc9bMjeyr1+nbHMz-+JygPFhOJ7MgcGtOd@mail.gmail.com>
References: <AANLkTi==qFhvSS33V9ERe_guHnCPfj0t01F9NVu7QqFK@mail.gmail.com>
	<AANLkTik=6gYQAa6gB7cLycq9KJ4GhZ3O7QMMrVa5vmXJ@mail.gmail.com>
	<AANLkTikJR4yc9bMjeyr1+nbHMz-+JygPFhOJ7MgcGtOd@mail.gmail.com>
Message-ID: <AANLkTinNt11pbBm9_SE7BPgirZR0bQ2VMiPu0HGjV70N@mail.gmail.com>

For GUI Automation, there are a couple of options. My favorite is LDTP [0].

Should be available as a package for your OS of choice. If ldtp2 is
available it is preferable to the original.

There is a tutorial at [1] and API docs are at [2]. Support via
mailing list and #ldtp on Freenode.

[0] http://ldtp.freedesktop.org/wiki/
[1] http://ldtp.freedesktop.org/wiki/LDTP_test_scripts_in_python
[2] http://ldtp.freedesktop.org/user-doc/index.html

2010/10/6 Daniel Gonz?lez Gasull <daniel at djansoft.com>:
> On Sat, Oct 2, 2010 at 9:53 AM, Luca Pellicoro <luca.pellicoro at gmail.com> wrote:
>> Just ran into Pexpect a few minutes ago. Is this what you're looking for?
>> http://www.noah.org/wiki/Pexpect#Overview
>
> Thank you for sharing this.
>
> I wonder if there is something similar for the X Window System. ?I use GNOME.
>
> --
> http://DjanSoft.com :: Agile Application Development with Python
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

From bbdada at gmail.com  Thu Oct  7 22:57:33 2010
From: bbdada at gmail.com (Nick S Kanakakorn)
Date: Thu, 7 Oct 2010 13:57:33 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTin-9HXd-i0W1w2hCayTvodyZiLf5JYS8_JnwY3i@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<AANLkTi=jKHF9zHaPG=1SZngW+w=kSW8o9QxMcM16rm3z@mail.gmail.com>
	<918DB0BF-8806-430E-92F6-CEE14A0FC1E7@dalkescientific.com>
	<AANLkTin-9HXd-i0W1w2hCayTvodyZiLf5JYS8_JnwY3i@mail.gmail.com>
Message-ID: <AANLkTimD7ysUdMhPACYCc9ycx5pVY_QoR_x+0fjbFWsU@mail.gmail.com>

Brent,

The rules changed after one day.  Now, I can use exception again.
Off topics: if python have command alias, I can say 'alias error raise'

-Nick

On Wed, Oct 6, 2010 at 2:28 PM, Brent Tubbs <brent.tubbs at gmail.com> wrote:

> Nick: Is your boss likely to notice something like this?
>
> (except.py)
> class TotallyNotAnExceptionNothingToSeeHere(Exception):
>    pass
>
> raise TotallyNotAnExceptionNothingToSeeHere("Really, pay me no attention")
>
> brent at greta:~/tmp$ python except.py
> Traceback (most recent call last):
>  File "except.py", line 4, in <module>
>    raise TotallyNotAnExceptionNothingToSeeHere("Really, pay me no
> attention")
> __main__.TotallyNotAnExceptionNothingToSeeHere: Really, pay me no attention
>
> Kidding.... mostly.  The "no exceptions" rule just seems really arbitrary.
>
> Brent
>
> On Wed, Oct 6, 2010 at 8:01 AM, Andrew Dalke <dalke at dalkescientific.com>
> wrote:
> > On Oct 5, 2010, at 9:57 PM, James Tatum wrote:
> >> I've seen this anti-pattern up close. There is no Pythonic answer -
> >> exceptions are the answer.
> >
> > There is a Pythonic answer - you can go the Twisted route.
> > (Excepting those who think Twisted isn't Pythonic. ;)
> >
> > Twisted's Deferreds can't use the stack because they
> > implement continuations through callback methods. You
> > "addCallback" for the normal case and "addErrback" for the
> > exceptions.
> >
> > It's possible to develop your entire code base this way.
> >
> > It's going to be structured entirely different than what
> > the OP's more senior rule mandator expects, but that might
> > be a good thing here.
> >
> >
> >                                Andrew
> >                                dalke at dalkescientific.com
> >
> >
> > _______________________________________________
> > Baypiggies mailing list
> > Baypiggies at python.org
> > To change your subscription options or unsubscribe:
> > http://mail.python.org/mailman/listinfo/baypiggies
> >
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>



-- 
-Nick Kanakakorn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101007/6f46ff85/attachment.html>

From bbdada at gmail.com  Thu Oct  7 23:12:14 2010
From: bbdada at gmail.com (Nick S Kanakakorn)
Date: Thu, 7 Oct 2010 14:12:14 -0700
Subject: [Baypiggies] running code in different stack frame
Message-ID: <AANLkTimTt_0WZgY8VDxi0g6M_DBTvH_fTaSytCjaa9Ha@mail.gmail.com>

Hi,

Is there anyway to specify that I want a block or function to work in
different stack frame in python ?
I'm thinking about something like this:

def check_something(magic_stack_frame, blah):
    if blah > 10
      return "Error...."
    else:
      # do something
    return


def myf():
   blah = 20
   check_something(current_stack_frame, blah)
   print('should not be here')

In this case, I don't want to see the message 'should not be here'.  The
return "Error ...." should be done as if check_something
is in the same stack frame of myf() instead of check_something

Thanks,

-- 
-Nick Kanakakorn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101007/def847e7/attachment.html>

From glen at glenjarvis.com  Thu Oct  7 23:18:45 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Thu, 7 Oct 2010 14:18:45 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTi=HFTxxD=7KJT5zaSnGf5k_jC+0r-QcKaU3cTWZ@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<AANLkTi=HFTxxD=7KJT5zaSnGf5k_jC+0r-QcKaU3cTWZ@mail.gmail.com>
Message-ID: <AANLkTik_SDa0MwgHuNqGjfziUyFVCtn-vQE4yXDs-LBe@mail.gmail.com>

EXCELLENT NEWS, Nick!!!

Raising is in PEP-8 (http://www.python.org/dev/peps/pep-0008/) and I
personally couldn't find a pythonic way to do this otherwise...

Glen

On Wed, Oct 6, 2010 at 2:50 PM, Nick S Kanakakorn <bbdada at gmail.com> wrote:

> There is a happy news here today.  The use of raise exception is allowed
> again after I put some coding in using this convention:
>
> exitcode, actual_result = f1()
> if exitcode < 0: return exitcode
> .... continue something useful with actual_result
> exitcode, actual_result = f1()
>
>
>
> On Tue, Oct 5, 2010 at 7:15 PM, Nick S Kanakakorn <bbdada at gmail.com>wrote:
>
>> Hi,
>>
>> My work place has imposed a rules for no use of exception (catching is
>> allowed).  If I have code like this
>>
>> def f1()
>>   if bad_thing_happen():
>>      raise Exception('bad stuff')
>>   ...
>>   return something
>>
>> I could change it to
>>
>> def f1()
>>   if bad_thing_happen():
>>     return [-1, None]
>>   ...
>>   return [0, something]
>>
>> f1 caller would be like this
>>
>> def f1_caller():
>>   code, result = f1(param1)
>>   if code < 0:
>>     return code
>>   actual_work1()
>>   # call f1 again
>>   code, result = f1(param2)
>>   if code < 0:
>>     return code
>>   actual_work2()
>>   ...
>>
>> Are there more elegant ways than this in Python ?
>>
>> Thanks,
>> Nick K
>>
>>
>
>
> --
> -Nick Kanakakorn
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>



-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101007/476ad927/attachment-0001.html>

From keith at dartworks.biz  Thu Oct  7 23:30:05 2010
From: keith at dartworks.biz (Keith Dart)
Date: Thu, 7 Oct 2010 14:30:05 -0700
Subject: [Baypiggies] running code in different stack frame
In-Reply-To: <AANLkTimTt_0WZgY8VDxi0g6M_DBTvH_fTaSytCjaa9Ha@mail.gmail.com>
References: <AANLkTimTt_0WZgY8VDxi0g6M_DBTvH_fTaSytCjaa9Ha@mail.gmail.com>
Message-ID: <20101007143005.66feb61a@dartworks.biz>

=== On Thu, 10/07, Nick S Kanakakorn wrote: ===
> Is there anyway to specify that I want a block or function to work in
> different stack frame in python ?

===

google for "stackless python" ;-)


-- Keith Dart

-- 
-- ------------------------------
Keith Dart
=================================


From aahz at pythoncraft.com  Fri Oct  8 00:54:31 2010
From: aahz at pythoncraft.com (Aahz)
Date: Thu, 7 Oct 2010 15:54:31 -0700
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
Message-ID: <20101007225431.GA19505@panix.com>

On Tue, Oct 05, 2010, Nick S Kanakakorn wrote:
>
> My work place has imposed a rules for no use of exception (catching is
> allowed).  

I've already read the whole thread and I see that this has been
rescinded, but I wanted to point out that it's literally impossible to
write certain kinds of Python programs without exceptions because Python
uses exceptions internally for control flow that is NOT an error.  See
for example StopIteration.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair

From kurtiss+recruiting at playhaven.com  Fri Oct  8 01:05:12 2010
From: kurtiss+recruiting at playhaven.com (Kurtiss Hare)
Date: Thu, 7 Oct 2010 16:05:12 -0700
Subject: [Baypiggies] Hiring Experienced Developer @ PlayHaven
Message-ID: <AANLkTi=imhunUeG=dLgXWO+ViWWF-AVO3BsY5=uwzdPu@mail.gmail.com>

Dear Piggies,

PlayHaven is a VC-backed startup disrupting the mobile games discovery and
marketing space. We're currently reaching more than 10 million mobile
gamers, and we're just getting started.  We're looking for self-motivated,
experienced, server-side Python developers who can help us deliver exciting
features and rock-solid reliability.  Let's displace the App Store, let's
deliver the highest quality game recommendations possible, and let's do it
together.

Take a look at our full job listing here:

http://github.com/playhaven/jobs/blob/master/core-software-engineer/README.rst

Then, send your resume and thoughts to jobs at playhaven.com.

-Kurtiss Hare
PlayHaven, CTO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101007/dfc7763c/attachment.html>

From jjinux at gmail.com  Fri Oct  8 02:03:53 2010
From: jjinux at gmail.com (Shannon -jj Behrens)
Date: Thu, 7 Oct 2010 17:03:53 -0700
Subject: [Baypiggies] running code in different stack frame
In-Reply-To: <AANLkTimTt_0WZgY8VDxi0g6M_DBTvH_fTaSytCjaa9Ha@mail.gmail.com>
References: <AANLkTimTt_0WZgY8VDxi0g6M_DBTvH_fTaSytCjaa9Ha@mail.gmail.com>
Message-ID: <AANLkTinn4+zpn_-sStr64+VfDPVd_5y5Vs3REFuQDU1h@mail.gmail.com>

Raise and catch an exception. Use the exception to get a hold of the
caller's stack frame so you can play with its locals. I used this trick once
to implement a templating library called evalstr.

On Oct 7, 2010 2:12 PM, "Nick S Kanakakorn" <bbdada at gmail.com> wrote:

Hi,

Is there anyway to specify that I want a block or function to work in
different stack frame in python ?
I'm thinking about something like this:

def check_something(magic_stack_frame, blah):
    if blah > 10
      return "Error...."
    else:
      # do something
    return


def myf():
   blah = 20
   check_something(current_stack_frame, blah)
   print('should not be here')

In this case, I don't want to see the message 'should not be here'.  The
return "Error ...." should be done as if check_something
is in the same stack frame of myf() instead of check_something

Thanks,

-- 
-Nick Kanakakorn

_______________________________________________
Baypiggies mailing list
Baypiggies at python.org
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101007/623afa21/attachment.html>

From fperez.net at gmail.com  Fri Oct  8 03:37:04 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 7 Oct 2010 18:37:04 -0700
Subject: [Baypiggies] [ANN - Py4Science@Cal] Oct 13: Strflab in python: a
 regularized regression framework
Message-ID: <AANLkTi=pphLpnm7rLtZ5iXZ8JEoSgCDyN_is8vdFc_7o@mail.gmail.com>

Hi all,

Next week, we'll have a discussion about time-series analysis tools
that build on work from several Berkeley labs.  While originating in
elctrophysiology, the tools discussed should be of interest to those
with data other sources as well.

I would appreciate it if you pass this info along to colleagues and
labs who might find the discussion worthwhile.

Cheers,

f


*Py4Science at Cal meeting*

Title: Strflab in python: a regularized regression framework

Speaker: James Gao, U.C. Berkeley

Abstract:
STRFlab is a Matlab toolkit originally used for performing regularized
regression on electrophysiological data. More recent work with MRI
showed that STRFlab's potential is not restricted to single cell
recordings, and can be used for a variety of brain data. Unfortunately
limitations of Matlab make it harder to work with larger data sets
such as those used in MRI. Python's support for objects and
referencing makes it an ideal platform for a STRFlab port. One of the
biggest hurdles for a successful port is the design of an efficient
data handling mechanism. The ideal system would support indexing into
arbitrary arrays such as numpy arrays, HDF files, etc; arbitrary
division of sample and heldout sets, as well as automated division for
bootstrapping and cross-validation. Some early code has been written
to address this, however I would appreciate community input on the
design.

When: Wednesday, October 13, 2010, 2pm.

Where: 508-20 Evans Hall (Redwood Center conference room)

For more information: https://cirl.berkeley.edu/view/Py4Science/WebHome

From sfseth at gmail.com  Fri Oct  8 04:32:18 2010
From: sfseth at gmail.com (Seth Friedman)
Date: Thu, 7 Oct 2010 19:32:18 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
Message-ID: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>

Hi Baypiggies,

I've encountered, a couple of times now, a sort of categorical "dont do
typechecking" attitude on various blog posts and I haven't seen rationale to
back it up.   Enough that I'm now curious: what's the deal?

So I put the question to you all, typechecking: good or bad thing?  Or
pointless philosophical debate?

The best argument I can think of for typechecking=bad is that if underlying
functions can take more types than obvious, let it try to do the right
thing, and if it fails, another exception will be likely anyway.   I mean
the TypeError raised with '1'+1 is pretty clear ("cannot concatenate 'str'
and 'int' objects"), but if it were more complex logic say with home-built
exceptions expected to highlight the error, I am skeptical.

I guess a second-best argument I can imagine is about false-negatives ..
what if I am overly restrictive in my type check and it fails when the (my)
logic would have succeeded.   Well, ok, as with anything gotta be careful
with typechecking as with the rest of the code.  But what if code around my
function is expecting ints and not floats even if my function can deal with
both.

If I'm writing the function and I know I only wrote it to accept single
numbers and not, for example lists or strings, isn't it cleaner to have at
the top of my function something like:

numbersoaccept=(int,float)
assert(isinstance(inputvar,numberstoaccept))
?

If I don't do this easy check it seems like failures down the road are
likely to be more convoluted and require more debugging time.   And is there
a better/more pythonic form of typechecking than this assert?  If I need to
extend my function to convert a string '1' to an int or to handle lists, it
seems better to have an assert that prompts me to remember that there's a
decision to be made about where to put that logic.  It's kind of like
executable documentation, what's the downside?

Best
seth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101007/75508b24/attachment-0001.html>

From mvoorhie at yahoo.com  Fri Oct  8 05:20:40 2010
From: mvoorhie at yahoo.com (Mark Voorhies)
Date: Thu, 7 Oct 2010 20:20:40 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
Message-ID: <201010072020.40425.mvoorhie@yahoo.com>

On Thursday, October 07, 2010 07:32:18 pm Seth Friedman wrote:
> Hi Baypiggies,
> 
> I've encountered, a couple of times now, a sort of categorical "dont do
> typechecking" attitude on various blog posts and I haven't seen rationale to
> back it up.   Enough that I'm now curious: what's the deal?
> 
> So I put the question to you all, typechecking: good or bad thing?  Or
> pointless philosophical debate?

The lack of type signatures in function declarations are in line with "Python
as a rapid prototyping language" -- if you're spending a lot of lines on "gatekeeping"
a function's arguments, you might be better off in a language that does that
work for you (e.g., Java, C++, ...).  There is a similar argument for not putting
a lot of work into enforcing private variables in Python.

That said, I don't have a strong opinion on this, and I've heard the "traits" system
in the Enthought Python Distribution recommended as a way to assert more
control over the types that a function accepts.

--Mark

From sfseth at gmail.com  Fri Oct  8 06:22:02 2010
From: sfseth at gmail.com (Seth Friedman)
Date: Thu, 7 Oct 2010 21:22:02 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <201010072020.40425.mvoorhie@yahoo.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<201010072020.40425.mvoorhie@yahoo.com>
Message-ID: <AANLkTim0xs_JjqZSV_-pQGC_3xntRBOom12eLYewQ+DC@mail.gmail.com>

Hi Mark,

Thanks for your response.

I can't quite wrap my head around your argument.  I don't think one or two
lines per input is a lot of / too much time gatekeeping input variables.
Philisophically I think I see your point, I'm trying to impose some rigidity
in a domain that doesn't like it.  But there are lots of other values that
python brings - it seems extreme to go to a different super-verbose language
just for type-checking.  Not to mention that I don't trust those other
languages to actually do it for me as well as python's assert(isinstance...)
style - Java for instance strikes me as a prime candidate for false-negative
type checking, they've got a lot of subtle type variations.

Is something like
assert(isinstance(inputNumber,isActuallyANumberWeExpected)) really that
cumbersome, aside from my long variable names?  The biggest examples I can
think of are the distinctions between number and string of number, and list
of numbers, which seem like totally legit "how far does this function need
to go" question, asserting what is expected seems to illuminate rather than
confuse.

I mean, what's wrong with code asserting that what it got passed was what
was expected?  If there's blind faith that stuff will just work beneath the
scenes, ok, but when i *know* it won't, why not fail there, and explicitly?
  If I write a function that can be called from python code or command line,
I might get a string of a number or an int, and I will probably forget 6
months from now what I wrote the code to handle, without some kind of
prompt.  The closer that prompt is to the disconnect, the better.

~seth

On Thu, Oct 7, 2010 at 8:20 PM, Mark Voorhies <mvoorhie at yahoo.com> wrote:

> On Thursday, October 07, 2010 07:32:18 pm Seth Friedman wrote:
> > Hi Baypiggies,
> >
> > I've encountered, a couple of times now, a sort of categorical "dont do
> > typechecking" attitude on various blog posts and I haven't seen rationale
> to
> > back it up.   Enough that I'm now curious: what's the deal?
> >
> > So I put the question to you all, typechecking: good or bad thing?  Or
> > pointless philosophical debate?
>
> The lack of type signatures in function declarations are in line with
> "Python
> as a rapid prototyping language" -- if you're spending a lot of lines on
> "gatekeeping"
> a function's arguments, you might be better off in a language that does
> that
> work for you (e.g., Java, C++, ...).  There is a similar argument for not
> putting
> a lot of work into enforcing private variables in Python.
>
> That said, I don't have a strong opinion on this, and I've heard the
> "traits" system
> in the Enthought Python Distribution recommended as a way to assert more
> control over the types that a function accepts.
>
> --Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101007/d9cf35da/attachment.html>

From keith at dartworks.biz  Fri Oct  8 06:49:52 2010
From: keith at dartworks.biz (Keith Dart)
Date: Thu, 7 Oct 2010 21:49:52 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTim0xs_JjqZSV_-pQGC_3xntRBOom12eLYewQ+DC@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<201010072020.40425.mvoorhie@yahoo.com>
	<AANLkTim0xs_JjqZSV_-pQGC_3xntRBOom12eLYewQ+DC@mail.gmail.com>
Message-ID: <20101007214952.4ece0ebc@dartworks.biz>

=== On Thu, 10/07, Seth Friedman wrote: ===
> Is something like
> assert(isinstance(inputNumber,isActuallyANumberWeExpected)) really
> that cumbersome, aside from my long variable names?  

I don't see that as any better than just using it directly. In the
assert case you may get an AssertError thrown that you will have to
catch somewhere. But if you just apply the operator you get a TypeError
thrown that you have to catch somewhere. I think Python is a
"optimistic" language. You just go and do it and catch errors if they
happen.

An alternative is to "cast" it. if you really don't know what you're
getting, just use something like "int(inputNumber) + 1" which works as
long as the input can be converted. I think that's related to the "duck
typing" that is pervasive in Python.


> I mean, what's wrong with code asserting that what it got passed was
> what was expected?  If there's blind faith that stuff will just work
> beneath the scenes, ok, but when i *know* it won't, why not fail
> there, and explicitly? 

It will fail anyway, and explicitly, with a TypeError. Python is already
doing the type checking "under the hood", so you don't have to add that
extra layer.

> If I write a function that can be called from
> python code or command line, I might get a string of a number or an
> int, and I will probably forget 6 months from now what I wrote the
> code to handle, without some kind of prompt.  The closer that prompt
> is to the disconnect, the better.

Right, so just do input validation up front. e.g. 

try:
  x = int(argv[1])
except (TypeError, ValueError, IndexError):
	print "You must supply an int."

From then on you know it's an int, no reason to double-check with an
assert later.

As for remembering what the function accepts, that's what doc strings
are for. ;-)

But an assert can't hurt, if you really want, for developing new code.
You can later run Python in optimized mode (-OO flag), and the asserts
are removed from the bytecode. But if you run in optimized mode and do
get a bad value you will in this case get the TypeError and not the
AssertError that you previously got. So the behavior will change
between the two modes.



 -- Keith Dart

-- 
-- ------------------------------
Keith Dart
=================================


From mvoorhie at yahoo.com  Fri Oct  8 06:47:54 2010
From: mvoorhie at yahoo.com (Mark Voorhies)
Date: Thu, 7 Oct 2010 21:47:54 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTim0xs_JjqZSV_-pQGC_3xntRBOom12eLYewQ+DC@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<201010072020.40425.mvoorhie@yahoo.com>
	<AANLkTim0xs_JjqZSV_-pQGC_3xntRBOom12eLYewQ+DC@mail.gmail.com>
Message-ID: <201010072147.54779.mvoorhie@yahoo.com>

On Thursday, October 07, 2010 09:22:02 pm Seth Friedman wrote:
> Hi Mark,
> 
> Thanks for your response.
> 
> I can't quite wrap my head around your argument.  I don't think one or two
> lines per input is a lot of / too much time gatekeeping input variables.
> Philisophically I think I see your point, I'm trying to impose some rigidity
> in a domain that doesn't like it.  But there are lots of other values that
> python brings - it seems extreme to go to a different super-verbose language
> just for type-checking.  

Agreed.  Any language will provide some of the features you want, and you'll
wind up implementing the rest yourself; the trick is to match your project to
the language that will do most of the heavy lifting for you (and quite often,
that language turns out to be Python).

> Not to mention that I don't trust those other
> languages to actually do it for me as well as python's assert(isinstance...)
> style - Java for instance strikes me as a prime candidate for false-negative
> type checking, they've got a lot of subtle type variations.

The main thing that a more rigid language will do is to force type checking
even when you don't remember to ask for it.  Sometimes this is what you
want, sometime it isn't...

> 
> Is something like
> assert(isinstance(inputNumber,isActuallyANumberWeExpected)) really that
> cumbersome, aside from my long variable names?  The biggest examples I can
> think of are the distinctions between number and string of number, and list
> of numbers, which seem like totally legit "how far does this function need
> to go" question, asserting what is expected seems to illuminate rather than
> confuse.

In some of these cases, the pythonic thing to do is to use duck typing; e.g.,
rather than checking for a list _type_, check that you've been passed an
iterable (deriving from any base).

> 
> I mean, what's wrong with code asserting that what it got passed was what
> was expected?  

Nothing, and I think most python programmers would support sanitizing your
inputs, but asserting certain properties of your inputs does not always imply
asserting that they are instances of specific class (and sometimes it does,
and that's okay too).

--Mark

> If there's blind faith that stuff will just work beneath the
> scenes, ok, but when i *know* it won't, why not fail there, and explicitly?
>   If I write a function that can be called from python code or command line,
> I might get a string of a number or an int, and I will probably forget 6
> months from now what I wrote the code to handle, without some kind of
> prompt.  The closer that prompt is to the disconnect, the better.
> 
> ~seth
> 
> On Thu, Oct 7, 2010 at 8:20 PM, Mark Voorhies <mvoorhie at yahoo.com> wrote:
> 
> > On Thursday, October 07, 2010 07:32:18 pm Seth Friedman wrote:
> > > Hi Baypiggies,
> > >
> > > I've encountered, a couple of times now, a sort of categorical "dont do
> > > typechecking" attitude on various blog posts and I haven't seen rationale
> > to
> > > back it up.   Enough that I'm now curious: what's the deal?
> > >
> > > So I put the question to you all, typechecking: good or bad thing?  Or
> > > pointless philosophical debate?
> >
> > The lack of type signatures in function declarations are in line with
> > "Python
> > as a rapid prototyping language" -- if you're spending a lot of lines on
> > "gatekeeping"
> > a function's arguments, you might be better off in a language that does
> > that
> > work for you (e.g., Java, C++, ...).  There is a similar argument for not
> > putting
> > a lot of work into enforcing private variables in Python.
> >
> > That said, I don't have a strong opinion on this, and I've heard the
> > "traits" system
> > in the Enthought Python Distribution recommended as a way to assert more
> > control over the types that a function accepts.
> >
> > --Mark
> >
> 

From jimmy at retzlaff.com  Fri Oct  8 08:39:45 2010
From: jimmy at retzlaff.com (Jimmy Retzlaff)
Date: Thu, 7 Oct 2010 23:39:45 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTim0xs_JjqZSV_-pQGC_3xntRBOom12eLYewQ+DC@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<201010072020.40425.mvoorhie@yahoo.com>
	<AANLkTim0xs_JjqZSV_-pQGC_3xntRBOom12eLYewQ+DC@mail.gmail.com>
Message-ID: <AANLkTi=H9a6LRUUCgnnG0jFzeet6Td91OmbExV6E72F6@mail.gmail.com>

On Thu, Oct 7, 2010 at 9:22 PM, Seth Friedman <sfseth at gmail.com> wrote:
> I mean, what's wrong with code asserting that what it got passed was what
> was expected? ?If there's blind faith that stuff will just work beneath the
> scenes, ok, but when i *know* it won't, why not fail there, and explicitly?
> ? If I write a function that can be called from python code or command line,
> I might get a string of a number or an int, and I will probably forget 6
> months from now what I wrote the code to handle, without some kind of
> prompt. ?The closer that prompt is to the disconnect, the better.

The other side of this is that your function might work perfectly well
with types you never anticipated. For example you might take an open
file as a parameter. If all you do is call read() on that file, and
don't do any type checking, then later you can also pass in a StringIO
object or an HTTP response object or anything that supports the same
read() call. Type assertions would limit this flexibility.

Jimmy

From jason.lai at gmail.com  Fri Oct  8 08:54:10 2010
From: jason.lai at gmail.com (Jason Lai)
Date: Thu, 7 Oct 2010 23:54:10 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTim0xs_JjqZSV_-pQGC_3xntRBOom12eLYewQ+DC@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<201010072020.40425.mvoorhie@yahoo.com>
	<AANLkTim0xs_JjqZSV_-pQGC_3xntRBOom12eLYewQ+DC@mail.gmail.com>
Message-ID: <AANLkTimokkxbNmVay1E41KzMMBxSOYGspTo-RNz4qzvg@mail.gmail.com>

As an alternative to an explicit assert, you may consider creating a
decorator, e.g.

@enforce_type(inputNumber = Number)
def myfunc(inputNumber):
    do_stuff()

That way, it separates the type checking from the main body of code, and
enforce_type could generate an appropriate detailed error message like
"myfunc expected inputNumber to be of type 'Number' but was passed 'str'"
which is nicer than just an assert. You could also easily demote it to a
warning rather than an exception without changing all of your code (e.g.
type enforcement only for debugging), although you might miss it if the
method just stores the argument and the type error doesn't happen until much
later, which is one argument for early typechecking.

Python 3.0 supports function annotations, which allows you to annotate
function parameters with arbitrary objects including type objects (although
it doesn't assign any special meaning to them), which would allow you to do
something like:

@enforce_types
def myfunc(inputNumber: Number):
    do_stuff()

Note that numbers.Number (which is a superclass of the standard number types
like int and float) is only available in Python 2.6+.

For non-numeric/non-string types though, you have to be more careful -- for
example it's not uncommon for people to pass around dictionary-like objects
that implement the usual x["key"] protocol but aren't actually dictionaries.
And file-like objects are enshrined in Python's API.

Python 2.6+ has the concept of Abstract Base Classes to allow type-checking
to ensure an object implements a particular interface. It seems a little
inconsistent though -- if you implement __iter__ on a random class MyClass
then isinstance(MyClass(), collections.Iterable) returns True. However, if
you try to implement the collections.Mapping ABC, simply implementing the
methods __getitem__, __iter__, and __len__ is insufficient;
isinstance(MyClass(), collections.Mapping) will return False.

In that case, you have to make MyClass subclass collections.Mapping, or use
collections.Mapping.register(MyClass). This is OK if you control all the
code, since you can just make sure all your dictionary-like objects inherit
from the right ABC, but probably too strict for open-source library code
where most people expect to pass an object that looks like a dictionary and
have the duck typing just work.

You could potentially work around this in the type-checking decorator by, if
the initial type check fails, iterate over the __abstractmethods__ property
of the the required class and make sure all the necessary methods exist.

For your own user-defined classes which don't have a well-defined protocol
like the collection ABCs though, it's probably more trouble than it's worth
to define an explicit interface, in which case you might as well just stick
to duck typing.

 - Jason

On Thu, Oct 7, 2010 at 9:22 PM, Seth Friedman <sfseth at gmail.com> wrote:

> Hi Mark,
>
> Thanks for your response.
>
> I can't quite wrap my head around your argument.  I don't think one or two
> lines per input is a lot of / too much time gatekeeping input variables.
> Philisophically I think I see your point, I'm trying to impose some rigidity
> in a domain that doesn't like it.  But there are lots of other values that
> python brings - it seems extreme to go to a different super-verbose language
> just for type-checking.  Not to mention that I don't trust those other
> languages to actually do it for me as well as python's assert(isinstance...)
> style - Java for instance strikes me as a prime candidate for false-negative
> type checking, they've got a lot of subtle type variations.
>
> Is something like
> assert(isinstance(inputNumber,isActuallyANumberWeExpected)) really that
> cumbersome, aside from my long variable names?  The biggest examples I can
> think of are the distinctions between number and string of number, and list
> of numbers, which seem like totally legit "how far does this function need
> to go" question, asserting what is expected seems to illuminate rather than
> confuse.
>
> I mean, what's wrong with code asserting that what it got passed was what
> was expected?  If there's blind faith that stuff will just work beneath the
> scenes, ok, but when i *know* it won't, why not fail there, and explicitly?
>   If I write a function that can be called from python code or command line,
> I might get a string of a number or an int, and I will probably forget 6
> months from now what I wrote the code to handle, without some kind of
> prompt.  The closer that prompt is to the disconnect, the better.
>
> ~seth
>
> On Thu, Oct 7, 2010 at 8:20 PM, Mark Voorhies <mvoorhie at yahoo.com> wrote:
>
>> On Thursday, October 07, 2010 07:32:18 pm Seth Friedman wrote:
>> > Hi Baypiggies,
>> >
>> > I've encountered, a couple of times now, a sort of categorical "dont do
>> > typechecking" attitude on various blog posts and I haven't seen
>> rationale to
>> > back it up.   Enough that I'm now curious: what's the deal?
>> >
>> > So I put the question to you all, typechecking: good or bad thing?  Or
>> > pointless philosophical debate?
>>
>> The lack of type signatures in function declarations are in line with
>> "Python
>> as a rapid prototyping language" -- if you're spending a lot of lines on
>> "gatekeeping"
>> a function's arguments, you might be better off in a language that does
>> that
>> work for you (e.g., Java, C++, ...).  There is a similar argument for not
>> putting
>> a lot of work into enforcing private variables in Python.
>>
>> That said, I don't have a strong opinion on this, and I've heard the
>> "traits" system
>> in the Enthought Python Distribution recommended as a way to assert more
>> control over the types that a function accepts.
>>
>> --Mark
>>
>
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101007/b0f98826/attachment.html>

From dalke at dalkescientific.com  Fri Oct  8 09:00:35 2010
From: dalke at dalkescientific.com (Andrew Dalke)
Date: Fri, 8 Oct 2010 01:00:35 -0600
Subject: [Baypiggies] Python way to avoid usage of raise
In-Reply-To: <20101007225431.GA19505@panix.com>
References: <AANLkTi=7MB0-7fJF1Vs81TnoCL5kf9eOR4Xm2yyX55Zu@mail.gmail.com>
	<20101007225431.GA19505@panix.com>
Message-ID: <19AB3C61-9499-48C1-AECC-2B3DC79B75F7@dalkescientific.com>

On Oct 7, 2010, at 4:54 PM, Aahz wrote:
> ... Python uses exceptions internally for control flow that is
> NOT an error.  See for example StopIteration.

But those don't need an explicit raise because they are so
easy to generate:

>>> def spam():
...   yield 1
...   yield 2
...   iter([]).next()
...   yield 3
... 
>>> for i in spam():
...   print i
... 
1
2
>>> 

In fact, this alternative is shorter

>>> len("raise StopIteration")
19
>>> len('iter([]).next()')
15
>>> 

I'm definitely not saying this is a good solution!

				Andrew
				dalke at dalkescientific.com



From jjinux at gmail.com  Fri Oct  8 18:59:42 2010
From: jjinux at gmail.com (Shannon -jj Behrens)
Date: Fri, 8 Oct 2010 09:59:42 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTimSEdnMU=0sNnKE5Gz7tTyuU6x=uKrVfAh8TJ6G@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<AANLkTimSEdnMU=0sNnKE5Gz7tTyuU6x=uKrVfAh8TJ6G@mail.gmail.com>
Message-ID: <AANLkTi=xAm+ORi9aT77F1qGWjZ1djK+uKJLuJdonRoKq@mail.gmail.com>

If you're on .net, check out Boo.  It's a language that has Python syntax
with static typing.

In Python, make sure your assertions aren't catching too much.  For
instance, if you're checking for float and int, you're leaving out decimal.

Letting the duck typing just do its job isn't as confusing as you might
think. It's not like you can't look at the whole stack trace to see who's to
blame (unless the value was saved in a container for later usage).

Most of my bugs come from not understanding the problem well enough--not
from type errors.  That being said, I'm still excited about Scala which has
a very rich static type system (yeah, yeah, go ahead and make fun of me ;)

Happy Hacking!

On Oct 7, 2010 7:32 PM, "Seth Friedman" <sfseth at gmail.com> wrote:

Hi Baypiggies,

I've encountered, a couple of times now, a sort of categorical "dont do
typechecking" attitude on various blog posts and I haven't seen rationale to
back it up.   Enough that I'm now curious: what's the deal?

So I put the question to you all, typechecking: good or bad thing?  Or
pointless philosophical debate?

The best argument I can think of for typechecking=bad is that if underlying
functions can take more types than obvious, let it try to do the right
thing, and if it fails, another exception will be likely anyway.   I mean
the TypeError raised with '1'+1 is pretty clear ("cannot concatenate 'str'
and 'int' objects"), but if it were more complex logic say with home-built
exceptions expected to highlight the error, I am skeptical.

I guess a second-best argument I can imagine is about false-negatives ..
what if I am overly restrictive in my type check and it fails when the (my)
logic would have succeeded.   Well, ok, as with anything gotta be careful
with typechecking as with the rest of the code.  But what if code around my
function is expecting ints and not floats even if my function can deal with
both.

If I'm writing the function and I know I only wrote it to accept single
numbers and not, for example lists or strings, isn't it cleaner to have at
the top of my function something like:

numbersoaccept=(int,float)
assert(isinstance(inputvar,numberstoaccept))
?

If I don't do this easy check it seems like failures down the road are
likely to be more convoluted and require more debugging time.   And is there
a better/more pythonic form of typechecking than this assert?  If I need to
extend my function to convert a string '1' to an int or to handle lists, it
seems better to have an assert that prompts me to remember that there's a
decision to be made about where to put that logic.  It's kind of like
executable documentation, what's the downside?

Best
seth

_______________________________________________
Baypiggies mailing list
Baypiggies at python.org
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101008/b84508a2/attachment.html>

From alexandre.conrad at gmail.com  Fri Oct  8 19:08:19 2010
From: alexandre.conrad at gmail.com (Alexandre Conrad)
Date: Fri, 8 Oct 2010 10:08:19 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
Message-ID: <AANLkTim-dfVHVAhfvQdap4mdv7hr1NNxD9G6csjE_GX5@mail.gmail.com>

2010/10/7 Seth Friedman <sfseth at gmail.com>:
> Hi Baypiggies,
> I've encountered, a couple of times now, a sort of categorical "dont do
> typechecking" attitude on various blog posts and I haven't seen rationale to
> back it up. ? Enough that I'm now curious: what's the deal?
> So I put the question to you all, typechecking: good or bad thing? ?Or
> pointless?philosophical?debate?

My general rule of thumb:

- do type checking/conversion as soon as you have input from an
external/untrusted source (e.g., data submitted from a POST request).

- if you need to convert data type, (e.g., a string "123" to an int
123), do it before passing it to your function. Don't have the
function do the data type checking (again, unless data comes from an
untrusted source). Make sure your functions receive the expected data
types as argument. If it crashes or you are getting unexpected
results, it means you are misusing your function (or your function has
a bug).

- keep your function's docstrings up to date. Always start saying what
the function will return (it may return different data types). If your
function expects specific data types, write it in the docstring as "In
the face of ambiguity, refuse the temptation to guess". If the
function accepts different types (say list, tuples, set, dict) because
it will, say, iterate over them, use the word "iterator" or "sequence
of <data type>" for the argument's doc (or anything that makes sense
to you, but preferably, that makes sense to everyone).

And remember: "Special cases aren't special enough to break the rules.
Although practicality beats purity." So sometimes, isinstance() is
useful (but if I use it, I try to rework my code so I don't have to,
plus, I think isinstance is rather slow).


> The best argument I can think of for typechecking=bad is that if underlying
> functions can take more types than obvious, let it try to do the right
> thing, and if it fails, another exception will be likely anyway. ? I mean
> the TypeError raised with '1'+1 is pretty clear ("cannot concatenate 'str'
> and 'int' objects"), but if it were more complex logic say with home-built
> exceptions expected to highlight the error, I am skeptical.
> I guess a second-best argument I can imagine is about false-negatives ..
> what if I am overly restrictive in my type check and it fails when the (my)
> logic would have succeeded. ? Well, ok, as with anything gotta be careful
> with typechecking as with the rest of the code. ?But what if code around my
> function is expecting ints and not floats even if my function can deal with
> both.
> If I'm writing the function and I know I only wrote it to accept single
> numbers and not, for example lists or strings, isn't it cleaner to have at
> the top of my function something like:
> numbersoaccept=(int,float)
> assert(isinstance(inputvar,numberstoaccept))
> ?
> If I don't do this easy check it seems like failures down the road are
> likely to be more convoluted and require more debugging time. ? And is there
> a better/more pythonic form of typechecking than this assert? ?If I need to
> extend my function to convert a string '1' to an int or to handle lists, it
> seems better to have an assert that prompts me to remember that there's a
> decision to be made about where to put that logic. ?It's kind of like
> executable documentation, what's the downside?
> Best
> seth
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>



-- 
Alex | twitter.com/alexconrad

From brent.tubbs at gmail.com  Fri Oct  8 21:07:31 2010
From: brent.tubbs at gmail.com (Brent Tubbs)
Date: Fri, 8 Oct 2010 12:07:31 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTimokkxbNmVay1E41KzMMBxSOYGspTo-RNz4qzvg@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<201010072020.40425.mvoorhie@yahoo.com>
	<AANLkTim0xs_JjqZSV_-pQGC_3xntRBOom12eLYewQ+DC@mail.gmail.com>
	<AANLkTimokkxbNmVay1E41KzMMBxSOYGspTo-RNz4qzvg@mail.gmail.com>
Message-ID: <AANLkTim2ZUQxa+Xj9m4_RMuzWjcZkEE83a+sf8B0c4Gh@mail.gmail.com>

Here's a decorator recipe from ActiveState that does something similar:

http://code.activestate.com/recipes/454322-type-checking-decorator/

It allows for overloading:

@require("x", int, float)
@require("y", float)
def foo(x, y):
    return x+y

print foo(1, 2.5)      # Prints 3.5.
print foo(2.0, 2.5)    # Prints 4.5.
print foo("asdf", 2.5) # Raises TypeError exception.
print foo(1, 2)        # Raises TypeError exception.

On Thu, Oct 7, 2010 at 11:54 PM, Jason Lai <jason.lai at gmail.com> wrote:
> As an alternative to an explicit assert, you may consider creating a
> decorator, e.g.
>
> @enforce_type(inputNumber = Number)
> def myfunc(inputNumber):
> ??? do_stuff()
>
> That way, it separates the type checking from the main body of code, and
> enforce_type could generate an appropriate detailed error message like
> "myfunc expected inputNumber to be of type 'Number' but was passed 'str'"
> which is nicer than just an assert. You could also easily demote it to a
> warning rather than an exception without changing all of your code (e.g.
> type enforcement only for debugging), although you might miss it if the
> method just stores the argument and the type error doesn't happen until much
> later, which is one argument for early typechecking.
>
> Python 3.0 supports function annotations, which allows you to annotate
> function parameters with arbitrary objects including type objects (although
> it doesn't assign any special meaning to them), which would allow you to do
> something like:
>
> @enforce_types
> def myfunc(inputNumber: Number):
> ??? do_stuff()
>
> Note that numbers.Number (which is a superclass of the standard number types
> like int and float) is only available in Python 2.6+.
>
> For non-numeric/non-string types though, you have to be more careful -- for
> example it's not uncommon for people to pass around dictionary-like objects
> that implement the usual x["key"] protocol but aren't actually dictionaries.
> And file-like objects are enshrined in Python's API.
>
> Python 2.6+ has the concept of Abstract Base Classes to allow type-checking
> to ensure an object implements a particular interface. It seems a little
> inconsistent though -- if you implement __iter__ on a random class MyClass
> then isinstance(MyClass(), collections.Iterable) returns True. However, if
> you try to implement the collections.Mapping ABC, simply implementing the
> methods __getitem__, __iter__, and __len__ is insufficient;
> isinstance(MyClass(), collections.Mapping) will return False.
>
> In that case, you have to make MyClass subclass collections.Mapping, or use
> collections.Mapping.register(MyClass). This is OK if you control all the
> code, since you can just make sure all your dictionary-like objects inherit
> from the right ABC, but probably too strict for open-source library code
> where most people expect to pass an object that looks like a dictionary and
> have the duck typing just work.
>
> You could potentially work around this in the type-checking decorator by, if
> the initial type check fails, iterate over the __abstractmethods__ property
> of the the required class and make sure all the necessary methods exist.
>
> For your own user-defined classes which don't have a well-defined protocol
> like the collection ABCs though, it's probably more trouble than it's worth
> to define an explicit interface, in which case you might as well just stick
> to duck typing.
>
> ?- Jason
>
> On Thu, Oct 7, 2010 at 9:22 PM, Seth Friedman <sfseth at gmail.com> wrote:
>>
>> Hi Mark,
>> Thanks for your response.
>> I can't quite wrap my head around your argument. ?I don't think one or two
>> lines per input is a lot of / too much time gatekeeping input variables.
>> Philisophically I think I see your point, I'm trying to impose some rigidity
>> in a domain that doesn't like it. ?But there are lots of other values that
>> python brings - it seems extreme to go to a different super-verbose language
>> just for type-checking. ?Not to mention that I don't trust those other
>> languages to actually do it for me as well as python's assert(isinstance...)
>> style - Java for instance strikes me as a prime candidate for false-negative
>> type checking, they've got a lot of subtle type variations.
>> Is something like
>> assert(isinstance(inputNumber,isActuallyANumberWeExpected)) really that
>> cumbersome, aside from my long variable names? ?The biggest examples I can
>> think of are the distinctions between number and string of number, and list
>> of numbers, which seem like totally legit "how far does this function need
>> to go" question, asserting what is expected seems to illuminate rather than
>> confuse.
>> I mean, what's wrong with code asserting that what it got passed was what
>> was expected? ?If there's blind faith that stuff will just work beneath the
>> scenes, ok, but when i *know* it won't, why not fail there, and explicitly?
>> ? If I write a function that can be called from python code or command line,
>> I might get a string of a number or an int, and I will probably forget 6
>> months from now what I wrote the code to handle, without some kind of
>> prompt. ?The closer that prompt is to the disconnect, the better.
>>
>> ~seth
>> On Thu, Oct 7, 2010 at 8:20 PM, Mark Voorhies <mvoorhie at yahoo.com> wrote:
>>>
>>> On Thursday, October 07, 2010 07:32:18 pm Seth Friedman wrote:
>>> > Hi Baypiggies,
>>> >
>>> > I've encountered, a couple of times now, a sort of categorical "dont do
>>> > typechecking" attitude on various blog posts and I haven't seen
>>> > rationale to
>>> > back it up. ? Enough that I'm now curious: what's the deal?
>>> >
>>> > So I put the question to you all, typechecking: good or bad thing? ?Or
>>> > pointless philosophical debate?
>>>
>>> The lack of type signatures in function declarations are in line with
>>> "Python
>>> as a rapid prototyping language" -- if you're spending a lot of lines on
>>> "gatekeeping"
>>> a function's arguments, you might be better off in a language that does
>>> that
>>> work for you (e.g., Java, C++, ...). ?There is a similar argument for not
>>> putting
>>> a lot of work into enforcing private variables in Python.
>>>
>>> That said, I don't have a strong opinion on this, and I've heard the
>>> "traits" system
>>> in the Enthought Python Distribution recommended as a way to assert more
>>> control over the types that a function accepts.
>>>
>>> --Mark
>>
>>
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> http://mail.python.org/mailman/listinfo/baypiggies
>
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

From shaleh at speakeasy.net  Sat Oct  9 06:56:15 2010
From: shaleh at speakeasy.net (Sean Perry)
Date: Fri, 08 Oct 2010 21:56:15 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTi=xAm+ORi9aT77F1qGWjZ1djK+uKJLuJdonRoKq@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<AANLkTimSEdnMU=0sNnKE5Gz7tTyuU6x=uKrVfAh8TJ6G@mail.gmail.com>
	<AANLkTi=xAm+ORi9aT77F1qGWjZ1djK+uKJLuJdonRoKq@mail.gmail.com>
Message-ID: <1286600175.7120.6.camel@aspire>

On Fri, 2010-10-08 at 09:59 -0700, Shannon -jj Behrens wrote:
> Most of my bugs come from not understanding the problem well
> enough--not from type errors.  That being said, I'm still excited
> about Scala which has a very rich static type system (yeah, yeah, go
> ahead and make fun of me ;)
> 

I like haskell for this too. However as others have commented here the
type system ends up being used for duck typing most of the time. It is
rare to say "this has to be an int" instead we just use it for math and
the compiler figures out I meant a Num instance.

Of course the coding ends up being similar to the suggestions elsewhere
in the thread to just be optimistic and catch the exceptions. The
difference is most of it is handled by the compilation phase instead of
at runtime.


From recursive.cookie.jar at gmail.com  Sat Oct  9 13:08:02 2010
From: recursive.cookie.jar at gmail.com (Zachary Collins)
Date: Sat, 9 Oct 2010 07:08:02 -0400
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <1286600175.7120.6.camel@aspire>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<AANLkTimSEdnMU=0sNnKE5Gz7tTyuU6x=uKrVfAh8TJ6G@mail.gmail.com>
	<AANLkTi=xAm+ORi9aT77F1qGWjZ1djK+uKJLuJdonRoKq@mail.gmail.com>
	<1286600175.7120.6.camel@aspire>
Message-ID: <AANLkTimtQahTEQbyEbkX=ZOj4334pPQoyAhoYohiyEma@mail.gmail.com>

Many points have been here, but I'd like to throw in my feelings about
it, because I really do feel strongly about typing.

It's really not the typing that is necessarily the gate keeping in
traditional typed systems.  It's the types.  And there's several
reasons for this.  Now, in the more trivial cases, like int, or
string, or whatever, it's pretty obvious what type you need.

But there are still actually alot of cases where the type of an object
is not clear at the time you get to coding it.  For instance, take
containers.  Which container is best for this problem?  Which is most
efficient based on scaling with data set X?  data set Y?

How about I don't care right now.  How about I just give you an object
that you can slice and I'll think about it later?

What if suddenly I need to keep a bunch of meta data associated with
that list and it is no longer a generic list type, but it needs to be
it's own special caching slice like class that knows how and when to
fetch data?  Do I want to have A.  had to spend the half an hour
before hand pondering the potential interface I might want based on
data I don't have yet or B.  Have to by hand change the type in
several places possibly scattered in several files just so the
compiler believes me that it is ok?

The gatekeeping in typing is the planning of "what type is this?"
Often I don't know.  I don't even know which functions I might call on
my variable y until I've actually written a few lines.  When I'm
prototyping, I like to keep design and actual prototyping as tightly
coupled as possible, because rarely can I or should I spend the time
before hand /knowing/ alot of the details of my interface.

Another reason I like python's hands off approach to private members
and typing is that... I don't trust other programmers to know what I
need to do.  Frankly, my belief is that the coder who is most
immediately writing software has priority over the guy who wrote the
lib 10 years ago.  If I need your private variable to hack around a
feature problem or bug, I don't want to have to ask "pretty please".
If I need to give you a type you didn't think about when you wrote
your library, I don't want to have to assure you that it's ok.  How
about I take responsibility for that?

2010/10/9 Sean Perry <shaleh at speakeasy.net>:
> On Fri, 2010-10-08 at 09:59 -0700, Shannon -jj Behrens wrote:
>> Most of my bugs come from not understanding the problem well
>> enough--not from type errors. ?That being said, I'm still excited
>> about Scala which has a very rich static type system (yeah, yeah, go
>> ahead and make fun of me ;)
>>
>
> I like haskell for this too. However as others have commented here the
> type system ends up being used for duck typing most of the time. It is
> rare to say "this has to be an int" instead we just use it for math and
> the compiler figures out I meant a Num instance.
>
> Of course the coding ends up being similar to the suggestions elsewhere
> in the thread to just be optimistic and catch the exceptions. The
> difference is most of it is handled by the compilation phase instead of
> at runtime.
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

From charles.merriam at gmail.com  Sat Oct  9 18:09:20 2010
From: charles.merriam at gmail.com (Charles Merriam)
Date: Sat, 9 Oct 2010 09:09:20 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTimtQahTEQbyEbkX=ZOj4334pPQoyAhoYohiyEma@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<AANLkTimSEdnMU=0sNnKE5Gz7tTyuU6x=uKrVfAh8TJ6G@mail.gmail.com>
	<AANLkTi=xAm+ORi9aT77F1qGWjZ1djK+uKJLuJdonRoKq@mail.gmail.com>
	<1286600175.7120.6.camel@aspire>
	<AANLkTimtQahTEQbyEbkX=ZOj4334pPQoyAhoYohiyEma@mail.gmail.com>
Message-ID: <AANLkTi=QQxa+9wh-xFYk16RpXa9ZfGPbAp-i1c8soMDd@mail.gmail.com>

At the risk of diving into the religious debate, I'll add my thoughts:

1.  Type checking trades off catches programming errors at the cost of
programmer time.  Specific circumstances affect the answer, such has
how many different programmers will use a module.

2.  There are other trade offs related to type checking.  For example,
using the prefix "r" in front of raw input strings provides an
equivalent trade-off without using the internal type system.

As with any trade-off, it is safe to answer "it depends".

Charles Merriam

From aahz at pythoncraft.com  Sat Oct  9 18:18:40 2010
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 9 Oct 2010 09:18:40 -0700
Subject: [Baypiggies] Type checking - argument for it being bad	practice?
In-Reply-To: <AANLkTimtQahTEQbyEbkX=ZOj4334pPQoyAhoYohiyEma@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<AANLkTimSEdnMU=0sNnKE5Gz7tTyuU6x=uKrVfAh8TJ6G@mail.gmail.com>
	<AANLkTi=xAm+ORi9aT77F1qGWjZ1djK+uKJLuJdonRoKq@mail.gmail.com>
	<1286600175.7120.6.camel@aspire>
	<AANLkTimtQahTEQbyEbkX=ZOj4334pPQoyAhoYohiyEma@mail.gmail.com>
Message-ID: <20101009161840.GA17398@panix.com>

On Sat, Oct 09, 2010, Zachary Collins wrote:
>
> Another reason I like python's hands off approach to private members
> and typing is that... I don't trust other programmers to know what I
> need to do.  Frankly, my belief is that the coder who is most
> immediately writing software has priority over the guy who wrote the
> lib 10 years ago.  If I need your private variable to hack around a
> feature problem or bug, I don't want to have to ask "pretty please".
> If I need to give you a type you didn't think about when you wrote
> your library, I don't want to have to assure you that it's ok.  How
> about I take responsibility for that?

This is something I think about every time I deal with pycurl -- it
requires a real file object, not just a pseudo-file such as StringIO or
NamedTemporaryFile.  And I can see why the impedence mismatch between
pycurl and the underlying libcurl discouraged the pycurl programmers from
Doing The Right Thing.

So although I agree with you and although I get regularly annoyed at
pycurl, I am somewhat hesitant to cast stones as people who get it Wrong.

On the gripping hand, I am somewhat likely to discard pycurl if I get
enough tuits...
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair

From sfseth at gmail.com  Sat Oct  9 18:18:46 2010
From: sfseth at gmail.com (Seth Friedman)
Date: Sat, 9 Oct 2010 09:18:46 -0700
Subject: [Baypiggies] Type checking - argument for it being bad practice?
In-Reply-To: <AANLkTi=QQxa+9wh-xFYk16RpXa9ZfGPbAp-i1c8soMDd@mail.gmail.com>
References: <AANLkTi=CVRNZq75AJZRDBVO_Y_mqmd3vkGuzjK_bJBEO@mail.gmail.com>
	<AANLkTimSEdnMU=0sNnKE5Gz7tTyuU6x=uKrVfAh8TJ6G@mail.gmail.com>
	<AANLkTi=xAm+ORi9aT77F1qGWjZ1djK+uKJLuJdonRoKq@mail.gmail.com>
	<1286600175.7120.6.camel@aspire>
	<AANLkTimtQahTEQbyEbkX=ZOj4334pPQoyAhoYohiyEma@mail.gmail.com>
	<AANLkTi=QQxa+9wh-xFYk16RpXa9ZfGPbAp-i1c8soMDd@mail.gmail.com>
Message-ID: <AANLkTi=8sB=DiJ4G7Y802fOpVUfO2sJA_R9jjtnSgp7a@mail.gmail.com>

Hey everyone,

Thanks for all your thoughts, it's been educational.  I pretty much agree
with everything that's been said - I don't know the root of the "avoid type
checking!" school and maybe I was misinterpreting, but this has all been
very interesting.

About the "it depends" - totally.  I might be a more paranoid programmer
than average, but it's great to see so many takes on this problem space.

Thanks again,
~seth

On Sat, Oct 9, 2010 at 9:09 AM, Charles Merriam
<charles.merriam at gmail.com>wrote:

> At the risk of diving into the religious debate, I'll add my thoughts:
>
> 1.  Type checking trades off catches programming errors at the cost of
> programmer time.  Specific circumstances affect the answer, such has
> how many different programmers will use a module.
>
> 2.  There are other trade offs related to type checking.  For example,
> using the prefix "r" in front of raw input strings provides an
> equivalent trade-off without using the internal type system.
>
> As with any trade-off, it is safe to answer "it depends".
>
> Charles Merriam
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101009/6dcac81d/attachment.html>

From rami.chowdhury at gmail.com  Mon Oct 11 12:19:05 2010
From: rami.chowdhury at gmail.com (Rami Chowdhury)
Date: Mon, 11 Oct 2010 11:19:05 +0100
Subject: [Baypiggies] Fwd: [PyCon-Organizers] PyCon 2011 Poster Session CFP
	Now Open!
Message-ID: <201010111119.05065.rami.chowdhury@gmail.com>


==== PyCon 2011 Call for Posters ====

PyCon 2011 will be held March 9th-17th, 2011 in Atlanta,
Georgia. (Home of some of the best southern food you can possibly find
on Earth!) The PyCon conference days will be March 11-13, preceded by
two tutorial days (March 9-10), and followed by four days of development
sprints (March 14-17).

This is the second year that PyCon is offering a poster pession. A poster
is a 4' x 4' graphical summary of the key points about your project, and a
poster session provides another way of presenting that encourages more
one-on-one communication between the presenter and the audience. Poster
sessions are particularly suited for topics of interest to a subset of the
community and/or presenters who are more comfortable interacting with
smaller
groups. Poster sessions also are a great incubator for further hallway track
discussions.

Poster proposals will be accepted on a rolling basis until January 19 or we
reach the limit of 35 posters.

For general information on the poster session visit the PyCon site at
http://us.pycon.org/2011/speaker/posters/ , for a list of last year's
posters
go to http://us.pycon.org/2010/conference/posters/accepted/, or see the full
CFP for poster
proposals at http://us.pycon.org/2011/speaker/posters/cfp/.

To submit a poster proposal use the PyCon speaker submission system
found at http://us.pycon.org/2011/speaker/

See you in Atlanta!



From cappy2112 at gmail.com  Mon Oct 18 08:57:26 2010
From: cappy2112 at gmail.com (Tony Cappellini)
Date: Sun, 17 Oct 2010 23:57:26 -0700
Subject: [Baypiggies] Bugs.python.org down
Message-ID: <AANLkTikT_yPjWvhwxjWceNdfA_z2670bBGRp9cbA1KyK@mail.gmail.com>

Just my luck- the first time I need to use this site, and it's down

By the time most of you read this, it will be up again.

From keith at dartworks.biz  Mon Oct 18 09:40:37 2010
From: keith at dartworks.biz (Keith Dart)
Date: Mon, 18 Oct 2010 00:40:37 -0700
Subject: [Baypiggies] Bugs.python.org down
In-Reply-To: <AANLkTikT_yPjWvhwxjWceNdfA_z2670bBGRp9cbA1KyK@mail.gmail.com>
References: <AANLkTikT_yPjWvhwxjWceNdfA_z2670bBGRp9cbA1KyK@mail.gmail.com>
Message-ID: <20101018004037.7a690cd2@dartworks.biz>

=== On Sun, 10/17, Tony Cappellini wrote: ===
> Just my luck- the first time I need to use this site, and it's down
> 
> By the time most of you read this, it will be up again.

===

Thanks for sharing. ;-)


-- Keith Dart

-- 

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Keith Dart <keith at dartworks.biz>
   public key: ID: 19017044
   <http://www.dartworks.biz/>
   =====================================================================

From spmcinerney at hotmail.com  Fri Oct 22 14:46:01 2010
From: spmcinerney at hotmail.com (Stephen McInerney)
Date: Fri, 22 Oct 2010 05:46:01 -0700
Subject: [Baypiggies] baypiggies.net is down
Message-ID: <BAY155-w34470A84CC248666F488F6A05E0@phx.gbl>


baypiggies.net is down ("502 Bad Gateway")

Stephen
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101022/a80965f1/attachment.html>

From fperez.net at gmail.com  Sun Oct 24 18:14:52 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 24 Oct 2010 09:14:52 -0700
Subject: [Baypiggies] [ANN:Py4Science@Cal] October 27: Parallel IPython with
	ZeroMQ
Message-ID: <AANLkTi=Nh_epGV-z4wqmKOtNxqt8yCOKxkefeqb=y9Rk@mail.gmail.com>

Hi folks,

for next week, we have Min Ragan-Kelley presenting the new machinery
for parallel work in IPython that is now based on the ZeroMQ
architecture we discussed a few weeks ago.

Please forward this to any interested colleagues.

Cheers,

f

*Py4Science at Cal meeting*

Title: Parallel IPython with ZeroMQ

Speaker: Min Ragan-Kelley, U.C. Berkeley

Abstract:
IPython has provided interactive parallel computing for some time, but
there are limitations to the current use of the Twisted library for
networking.  Twisted is a high-level utility with many benefits, but
makes some critical functionality, such as non-copying sends,
impossible.  Using the low-level message passing library ZeroMQ for
communication has given us many advantages over Twisted, but also
introduces new challenges.  It is now possible to send a string or
numpy array (or anything that provides the buffer interface) with
exactly zero in-memory copies, dramatically improving performance for
large data messages.  In addition, a new function-based interface
mirroring multiprocessing's 'apply(f,args,kwargs)' allows executing
remote code to be more intuitive, so there will no longer be any need
to package code into strings for remote execution.  Preliminary tests
show 40-100x performance improvements over Twisted code for
high-frequency job submissions.

From fperez.net at gmail.com  Mon Oct 25 01:34:19 2010
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 24 Oct 2010 16:34:19 -0700
Subject: [Baypiggies] [ANN:Py4Science@Cal] October 27: Parallel IPython
	with ZeroMQ
In-Reply-To: <AANLkTi=Nh_epGV-z4wqmKOtNxqt8yCOKxkefeqb=y9Rk@mail.gmail.com>
References: <AANLkTi=Nh_epGV-z4wqmKOtNxqt8yCOKxkefeqb=y9Rk@mail.gmail.com>
Message-ID: <AANLkTi=HK+g1VkPd96Ed_C3u7S_OBLy=aBmjjFeqfWvn@mail.gmail.com>

On Sun, Oct 24, 2010 at 9:14 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> for next week, we have Min Ragan-Kelley presenting the new machinery
> for parallel work in IPython that is now based on the ZeroMQ
> architecture we discussed a few weeks ago.

Sorry, I forgot to add the time/place info and have already received a
few questions.

October 27, 2pm, 508-20 Evans Hall.

Campus map and parking info (parking is notoriously tricky in/around
campus, unfortunately):
http://berkeley.edu/map/

More details:
https://cirl.berkeley.edu/view/Py4Science

Cheers,

f

From jimmy at retzlaff.com  Wed Oct 27 01:22:21 2010
From: jimmy at retzlaff.com (Jimmy Retzlaff)
Date: Tue, 26 Oct 2010 16:22:21 -0700
Subject: [Baypiggies] Yelp Software Engineering Openings: Web, Backend,
	Search, Ads, and Mobile
Message-ID: <AANLkTikFqfMReCovbfcxyisnOWFEhHhBiE-v=e4aEc_D@mail.gmail.com>

Some of you know that I recently started working at Yelp in San
Francisco. Everything I've touched in my first 3 weeks is Python! I
hear there is also Java and C/C++ around, but I haven't run into it
yet. Everyone I've come across here is really smart and the
development process is all about producing high quality code in a
really productive way. If you're looking for hard-core Python work,
read on... and let me know if you have any questions or interest in
joining me.

Thanks,
Jimmy


Yelp has been connecting people with great local businesses since
2005. Yelp has grown to become the #1 local review and recommendation
website, attracting over 36 million unique users per month and has
over 2 million users on mobile clients (iPhone, Android, etc...).

What you need to know about Yelp Engineering:
* Team size? 40 engineers and 1 dog named Darwin.
* Release cycle? Daily, sometimes multiple times a day.
* Code-reviews? Required on every check-in.
* Source control? Git, duh.
* KegMate enabled kegs? 1 so far but more to come.
http://engineeringblog.yelp.com/2010/08/yelp-makes-beer-more-fun.html
* Hackathons? Every six months.
* Unit-tests? Lots of them. We use buildbot and testify. Required as
part of every check-in.

Web Developer
* Develop cool and useful features for our Yelp community
* Expertise in JavaScript, HTTP, HTML/DOM, and CSS

Search and Data-Mining Engineer
* Tackle machine learning and IR problems from our database of local
content (12M+ Yelp reviews)
* Strong grasp of algorithms and data structures; expertise in Python,
Java, or C++

Ads/Revenue Engineer
* ?Show me the money!? Use machine learning, statistic, economics, and
optimization to build and improve our ad targeting systems.
* Strong grasp of algorithms and data structures; expertise in Python,
Java, or C++

Back-end Engineer
* Build whole systems that are simple and scalable
* Expertise in your favorite modern programming language: Python,
Ruby, Java, and/or C++

Mobile Developer
* Create fun and useful mobile applications for the iPhone, Android,
Blackberry platforms and beyond
* Expertise in Objective C, Java and other mobile languages

Check out our brand new Yelp Engineering Blog -
http://engineeringblog.yelp.com/ - and read about a day in the life of
a Yelp engineer -
http://officialblog.yelp.com/2009/10/day-in-the-life-of-a-yelp-engineer.html

Want to join the team? Apply now!
http://www.yelp.com/careers?nl=1&jvi=oDTbVfwm,JobListing&jvs=BayPiggies

From jim at systemateka.com  Wed Oct 27 05:41:09 2010
From: jim at systemateka.com (jim)
Date: Tue, 26 Oct 2010 20:41:09 -0700
Subject: [Baypiggies] BayPIGgies meeting Thursday, October 28,
 2010: Consulting As a Career Choice
Message-ID: <1288150869.1875.4.camel@jim-laptop>


BayPIGgies meeting Thursday, October 28, 2010: Consulting As a Career
Choice


This meeting's talk is Consulting As a Career Choice 
by Glen Jarvis, Monte Davidoff,  Emile Van Sebille, Annette Bourget 

Tonight's talk is a four-person mini-talk and Q&A Panel:
* Business Resources Available to You -- Glen Jarvis
* A topic from Marketing and Networking -- Annet Bourget
* Issues of Business Entities/Legal Stuff -- Monte Davidoff
* Consulting vs. Contracting - Emile van Sebille


.........................................

Meetings usually start with a Newbie Nugget, a short discussion 
of an essential Python feature, especially for those new to 
Python. 
Tonight's Newbie Nugget: none. 


LOCATION 
Symantec Corporation
Symantec Vcafe
350 Ellis Street
Mountain View, CA 94043
http://maps.google.com/maps/ms?oe=utf-8&client=firefox-a&ie=UTF8&fb=1&split=1&gl=us&ei=w6i_Sfr6MZmQsQOzlv0v&hl=en&t=h&msa=0&msid=116202735295394761637.00046550c09ff3d96bff1&ll=37.397693,-122.053707&spn=0.002902,0.004828&z=18

BayPIGgies meeting information is available at 
http://www.baypiggies.net/ 


------------------------ Agenda ------------------------


..... 7:30 PM ...........................
General hubbub, inventory end-of-meeting announcements, 
any first-minute announcements. 


..... 7:35 PM to 7:35 PM ................
Tonight's Newbie Nugget: none. 


..... 7:35 PM to 8:40 PM (or so) ................
The talk: Consulting As a Career Choice  


..... 8:40 PM to 9:10 PM  ................
Questions and Answers 


..... 9:10 PM to 9:30 PM  ................
Mapping and Random Access

Mapping is a rapid-fire audience announcement of issues, 
hiring, events, and other topics. 

Random Access follows people immediately to allow follow 
up on the announcements and other interests.



From glen at glenjarvis.com  Fri Oct 29 21:29:42 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Fri, 29 Oct 2010 12:29:42 -0700
Subject: [Baypiggies] Fwd: SBA Classes November 1 - 12
In-Reply-To: <AB45D2D3A30DE2419C933553FDC98994120F4BCC@E2K3-DEN-EVS3.sba.gov>
References: <AB45D2D3A30DE2419C933553FDC98994120F4BCC@E2K3-DEN-EVS3.sba.gov>
Message-ID: <AANLkTimSfAs2fzYjteTO2XGJEOH-VsKM3MzXfe-f5AP2@mail.gmail.com>

I mentioned the Small Business Association's free classes yesterday and
handed out an older calendar. Here is the newer calendar for those
interested in free classes to learn how to still do Python (and get paid) -
even if it isn't working for someone else.

To get a calendar regularly, send an email to Gary Marshall requesting this.
His email follows.

Cheers,


Glen



---------- Forwarded message ----------
From: Marshall, Gary N. <gary.marshall at sba.gov>
Date: Thu, Oct 28, 2010 at 5:05 PM
Subject: SBA Classes November 1 - 12
To: "Marshall, Gary N." <gary.marshall at sba.gov>


 If you do not wish to receive future announcements of SBA events, please
reply to this email with the word ?Delete? in the subject line.  Thank you.

******

*TRAINING AT SBA*

*****The Small Business Administration offers a variety of classes for
business owners in our Entrepreneur Center, located at 455 Market St., 6th
Floor in downtown San Francisco.*

*****Registration for all our classes is required.*

*To register for classes, go to*
*http://sbatraining.eventbrite.com/*<http://sbatraining.eventbrite.com/>

For more information, please contact Gary Marshall at (415) 744 6771 or
gary.marshall at sba.gov

******

*****The SBA training program is made possible by the generous support of
our volunteer teachers and presenters.   We appreciate their time and
expertise; however, these presentations do not represent an endorsement of
their views, opinions, products, or services by SBA.  All SBA programs are
extended to the public on a nondiscriminatory basis. Reasonable arrangements
for persons with disabilities will be made, if requested at least 2 weeks in
advance.  Contact: Gary Marshall at 415 744-6771.*

********

*****Food Safety Certification*******

11/1

8:30 AM - 5:00 PM

State law requires that specified food facilities employ at least one person
who has successfully passed a California State approved and accredited food
safety certification exam.  Certification is mandatory and re-certification
is required every three years.  Registration and information is available at
*www.ggra.org*

*****Restaurant Series:  Ten Proven Techniques for Restaurant Marketing & PR
*

11/1

2:30 PM - 4:30 PM

Learn 10 must-have tricks of the trade to market your restaurant and keep
customers coming back. Session includes instruction and round table
discussion to solve current marketing challenges.  $30 registration fee.
Presented by the SF SBDC.

*****State Labor Law and Payroll Tax*

11/2

9:00 AM - 3:00 PM

Jointly conducted by the Employment Development Department and the
California state Department of Labor Standards Enforcement, this class will
cover California recordkeeping and reporting requirements including employer
obligations and payment requirements; common wage and hour laws; employer
and employee rights and responsibilities.  More information at (866)
873-6083, register at *www.edd.ca.gov/taxsem*

*****Buying a Business*

11/2

6:00 PM ? 8:30 PM

This class will address the practical aspects of buying an existing
business, including how to locate companies for sale, assessing value,
negotiating the purchase and financing alternatives for an acquisition.
Additionally, you will learn about the ensuing ?due diligence process?,
related to the buyer?s examination of books, records, etc., after the
buyer/seller have agreed to price and terms.

*****Personal Branding*******

11/2

6:00 PM ? 8:30 PM

You can create a powerful personal brand that will position yourself as an
expert in your industry. Ryan will take you through his Holistic Personal
Branding system for clarifying your unique combination of strengths. This
self-knowledge will provide the foundation to create your authentic personal
brand.

*****Starting a Business in San Francisco*

11/3

10:30 AM - 12:00 PM

Hear directly from San Francisco officials.  How do you obtain permits?  How
do you register your business name? Learn what the City can do for you in
this one-stop seminar.

*****Financing Your Business*

11/3

1:00 PM - 3:00 PM

Discover the right way to seek financing for your business. We will discuss
loan proposal requirements, financing options and SBA programs.

*****Business Law Basics*

11/3

3:30 PM - 5:30 PM

An experienced business lawyer will discuss Choice of Legal Entity
(corporations, LLC, partnership, etc.); Intellectual Property; Employee
issues; and Real Estate issues.   This class does not constitute legal
advice.

*****How to Design and Deliver Effective Presentations*

11/3

6:00 PM ? 8:30 PM

Learn to present effectively and confidently, whether in front of small or
large groups.  Content and exercises include engaging your audience;
designing an effective presentation and conquering your fear of speaking.

*****Basic Bookkeeping, Part One*

11/4

1:00 PM - 4:00 PM

Topics include cash vs. accrual accounting, proper accounting data flow
processes, budgeting, the purpose of different financial reports, the
differences in computer accounting systems, cash management, and more.  $30
registration fee.  Presented by the SF SBDC.

*****E-Marketing in Spanish*

11/4

6:00 PM - 9:00 PM

Learn how to use the Internet to market your business.    This will be a
hands-on class (lap tops will be provided during class.)  Areas covered
include:  Website development and Social Media, Facebook for Businesses.
$ 10 registration fee. Presented by the SF Business Development Center.

*****Wholesaling Tips of the Trade*

11/4

6:00 PM - 8:30 PM

Learn the smart way to run a wholesale operation.  Areas covered include
industry information and networking, cost vs. price, channel conflicts,
branding and wholesaling online.  $30 registration fee. Presented by the SF
Business Development Center.

*******Restaurant Series: Customer Service ? Good is Minimum*

*******11/8*

*1:00 PM - 4:00 PM*

To make your restaurant a success you need employees who know how to use
customer service to increase sales. Effective, transparent up selling will
increase profits and keep your customers hungry for more. Learn how to hire,
motivate and train your employees to meet the service demands of the
industry.  We will cover the basic principles of customer service and
hospitality, server sequencing, suggestive selling techniques as well as
problem solving and how to handle difficult guests. $30 registration fee.
Presented by the SF SBDC.

******

*Integrated Sales and Marketing Excellence*

11/8

6:00 PM - 8:30 PM

Marketing?s job is to bring in the prospects. Sales? job is to close the
deal and book revenues. This class teaches you how to implement an
integrated sales and marketing system that work together to produce results.
Learn the quantitative marketing and sales methods that work in a down turn.

*****Writing Effective Business Plans        *

11/9

9:00 AM ? 4:00 PM

Whether you are planning to start a new business or developing the potential
of your existing company, a business plan is a critical foundation. In this
hands-on workshop, we will demystify the process using case studies and
exercises. You will also develop a template for your own business that
covers Products/Services; Organization; Marketing; Customers; Finances;
Market Research. Presented by SF SCORE.  Registration fee: $50.

*****Basic Bookkeeping, Part Two*

11/9

1:00 PM - 4:00 PM

We?ll cover balance sheets, incomes statements, cash flow and working
capital.  Participants should have completed Basic Bookkeeping, Part One, or
be familiar with the concepts covered in that seminar.  $30 registration
fee.  Presented by the SF SBDC.

*****Getting Your To-Do List Done*

11/9

6:00 PM - 8:30 PM

Do you have a To-Do list that never gets done? Do you have items on your
To-Do list that have been on there for days, weeks, even months? Do you
stress out thinking about how you?re going to get it all done? In this
course you will learn how to organize, prioritize and analyze your to-do
list so that you actually get it done.



*****Secrets to Buying and Selling a Business or Franchise*

11/9

6:30 PM?8:30 PM

Learn how to reduce your risk and improve your chances of success in buying
or selling a franchise or existing business. This workshop covers the steps
necessary for you to succeed working with professionals, and using simple
research and qualification techniques. Topics include Choosing the Right
Franchise or Business, Positioning Your Business for Sale, and Buyer and
Seller Financing.  Presented by SF SCORE.  Registration fee: $20.

*****Mobile Marketing and the Mobile Web *

11/10

6:00 PM ? 7:30 PM

Mobile Web use is exploding!  Blackberries, iPhones, and other always-online
devices are everywhere. Discover what you need to know about this exciting
new medium. You'll learn: critical factors your website must  have;
avoidable pitfalls that send customers running; understanding the vast sea
of handheld devices; tremendous mobile marketing opportunities; and low cost
ways to get started now.

******

*OUR PARTNERS PRESENT:*

a weekly feature of events offered by organizations and groups outside SBA.
 These events are not sponsored by SBA and are not held at our Entrepreneur
Center.

******

*Small Business Dialogue Group*

Who we are: 10-15 sole proprietors or small businesses owners with one
employee or less looking to grow and thrive in spite of a tough economy. We
are looking to share ideas, tackle challenges, problem solve and build
successful and profitable businesses. This is an opportunity to dispel any
feelings of professional isolation and to work with other small businesses
and entrepreneurs for mutual but independent gain.******



Each member of the group gets to be the 'Business of the Month' for one
session, during which the group hears about what they do, sell or serve.
We listen and assess the good and the bad, what is successful and what
is challenging. The entire group brainstorms and provides constructive
feedback on ways to improve the Business of the Month.



Guest speakers will be invited based on the needs of the group, and may
include:

     -A marketing expert

     -A financial/bookkeeping/QuickBooks expert

     -A successful business owner



When and where we meet: Second Wednesday of every month for two hours in
rotating San Francisco locations



More info: Ellen Shershow Pe?a,
*thatgirl at ellenswebsite.com*<thatgirl at ellenswebsite.com>or
415.690.0278

******

*Where's the Money? 2nd Annual Access to Capital Business Expo*

Saturday, November 6, 2010

8am - 2:30pm ? Hyatt Regency

Five Embarcadero Center, San Francisco, CA 94111

Includes: Breakfast?Expo?Lunch?

Workshops?One on One Consultation

$10 registration fee.

Online: *www.vedc.org* <http://www.vedc.org>

Phone: (415) 541-8580

E-mail: *info at rencenter.org* <info at rencenter.org>******

******

Our mailing address:

Small Business Administration

455 Market St., 6th floor

San Francisco CA 94105

 thanks,

Gary

Gary Marshall

SBA Business Development Specialist

415 744 6771




-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101029/25bac372/attachment-0001.html>

From jimmy at retzlaff.com  Sat Oct 30 00:11:31 2010
From: jimmy at retzlaff.com (Jimmy Retzlaff)
Date: Fri, 29 Oct 2010 15:11:31 -0700
Subject: [Baypiggies] mrjob - distributed computing in Python made easy
Message-ID: <AANLkTinPX+zSmF3vLBsSxAj=Heb8b5WibHA+WiKJyLxx@mail.gmail.com>

Yelp has just open sourced mrjob. It's a package that makes doing
MapReduce in Python almost trivial. In as little as 10 lines of code
you can do MapReduce on your own computer. Add a handfull of lines of
configuration and you can be running your code unchanged in parallel
on dozens of machine on Amazon Elastic Map Reduce for a a few dollars
(a dozen "small" machines for an hour would be about $1). Dave, the
primary author just wrote up a post on our engineering blog:

http://engineeringblog.yelp.com/2010/10/mrjob-distributed-computing-for-everybody.html

I'm putting in a proposal to give a talk on mrjob at PyCon 2011.
Whether that's accepted or not, maybe I can give the same talk at
BayPIGgies in January or February if there's interest...

Jimmy

From simeonf at gmail.com  Sat Oct 30 00:22:17 2010
From: simeonf at gmail.com (Simeon Franklin)
Date: Fri, 29 Oct 2010 15:22:17 -0700
Subject: [Baypiggies] mrjob - distributed computing in Python made easy
In-Reply-To: <AANLkTinPX+zSmF3vLBsSxAj=Heb8b5WibHA+WiKJyLxx@mail.gmail.com>
References: <AANLkTinPX+zSmF3vLBsSxAj=Heb8b5WibHA+WiKJyLxx@mail.gmail.com>
Message-ID: <AANLkTinmssk0mdjPZZn0uMxbEH3WXCesqZ30vP=3_ub+@mail.gmail.com>

On Fri, Oct 29, 2010 at 3:11 PM, Jimmy Retzlaff <jimmy at retzlaff.com> wrote:

> I'm putting in a proposal to give a talk on mrjob at PyCon 2011.
> Whether that's accepted or not, maybe I can give the same talk at
> BayPIGgies in January or February if there's interest...
>

Sounds cool. +1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101029/8a660a84/attachment.html>

From tony at tcapp.com  Sat Oct 30 00:30:07 2010
From: tony at tcapp.com (Tony Cappellini)
Date: Fri, 29 Oct 2010 15:30:07 -0700
Subject: [Baypiggies] mrjob - distributed computing in Python made easy
In-Reply-To: <AANLkTinPX+zSmF3vLBsSxAj=Heb8b5WibHA+WiKJyLxx@mail.gmail.com>
References: <AANLkTinPX+zSmF3vLBsSxAj=Heb8b5WibHA+WiKJyLxx@mail.gmail.com>
Message-ID: <AANLkTinJ8pY=R7rDpD5+pJ3R7ExyvYfzaJhC6a6XBynx@mail.gmail.com>

You're On Jimmy! +1


On Fri, Oct 29, 2010 at 3:11 PM, Jimmy Retzlaff <jimmy at retzlaff.com> wrote:
> Yelp has just open sourced mrjob. It's a package that makes doing
> MapReduce in Python almost trivial. In as little as 10 lines of code
> you can do MapReduce on your own computer. Add a handfull of lines of
> configuration and you can be running your code unchanged in parallel
> on dozens of machine on Amazon Elastic Map Reduce for a a few dollars
> (a dozen "small" machines for an hour would be about $1). Dave, the
> primary author just wrote up a post on our engineering blog:
>
> http://engineeringblog.yelp.com/2010/10/mrjob-distributed-computing-for-everybody.html
>
> I'm putting in a proposal to give a talk on mrjob at PyCon 2011.
> Whether that's accepted or not, maybe I can give the same talk at
> BayPIGgies in January or February if there's interest...
>
> Jimmy
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>

From johan.mickelin at gmail.com  Sat Oct 30 00:30:36 2010
From: johan.mickelin at gmail.com (Johan Mickelin)
Date: Fri, 29 Oct 2010 15:30:36 -0700
Subject: [Baypiggies] mrjob - distributed computing in Python made easy
In-Reply-To: <AANLkTinmssk0mdjPZZn0uMxbEH3WXCesqZ30vP=3_ub+@mail.gmail.com>
References: <AANLkTinPX+zSmF3vLBsSxAj=Heb8b5WibHA+WiKJyLxx@mail.gmail.com>
	<AANLkTinmssk0mdjPZZn0uMxbEH3WXCesqZ30vP=3_ub+@mail.gmail.com>
Message-ID: <AANLkTi=F_TF1=GzdiKsWS4yz+Yfowcd04XCOLpPRDCZh@mail.gmail.com>

Sounds great, id go for sure

On Fri, Oct 29, 2010 at 3:22 PM, Simeon Franklin <simeonf at gmail.com> wrote:

> On Fri, Oct 29, 2010 at 3:11 PM, Jimmy Retzlaff <jimmy at retzlaff.com>wrote:
>
>> I'm putting in a proposal to give a talk on mrjob at PyCon 2011.
>> Whether that's accepted or not, maybe I can give the same talk at
>> BayPIGgies in January or February if there's interest...
>>
>
> Sounds cool. +1
>
>
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101029/9b8e6cb7/attachment.html>

From alexandre.conrad at gmail.com  Sat Oct 30 02:14:00 2010
From: alexandre.conrad at gmail.com (Alexandre Conrad)
Date: Fri, 29 Oct 2010 17:14:00 -0700
Subject: [Baypiggies] mrjob - distributed computing in Python made easy
In-Reply-To: <AANLkTinPX+zSmF3vLBsSxAj=Heb8b5WibHA+WiKJyLxx@mail.gmail.com>
References: <AANLkTinPX+zSmF3vLBsSxAj=Heb8b5WibHA+WiKJyLxx@mail.gmail.com>
Message-ID: <AANLkTi=yg5JC3Tk6zBRCwHYWMPfBom=g2rk-ot1Hg0uH@mail.gmail.com>

+1

2010/10/29 Jimmy Retzlaff <jimmy at retzlaff.com>:
> Yelp has just open sourced mrjob. It's a package that makes doing
> MapReduce in Python almost trivial. In as little as 10 lines of code
> you can do MapReduce on your own computer. Add a handfull of lines of
> configuration and you can be running your code unchanged in parallel
> on dozens of machine on Amazon Elastic Map Reduce for a a few dollars
> (a dozen "small" machines for an hour would be about $1). Dave, the
> primary author just wrote up a post on our engineering blog:
>
> http://engineeringblog.yelp.com/2010/10/mrjob-distributed-computing-for-everybody.html
>
> I'm putting in a proposal to give a talk on mrjob at PyCon 2011.
> Whether that's accepted or not, maybe I can give the same talk at
> BayPIGgies in January or February if there's interest...
>
> Jimmy
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>



-- 
Alex | twitter.com/alexconrad

From glen at glenjarvis.com  Sat Oct 30 00:44:47 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Fri, 29 Oct 2010 15:44:47 -0700
Subject: [Baypiggies] Fwd: SBA Classes November 1 - 12
In-Reply-To: <AB45D2D3A30DE2419C933553FDC98994120F4BCC@E2K3-DEN-EVS3.sba.gov>
References: <AB45D2D3A30DE2419C933553FDC98994120F4BCC@E2K3-DEN-EVS3.sba.gov>
Message-ID: <AANLkTimMarbU1pS1VKS37BZ-8rHckELZv03Vth-aOBsf@mail.gmail.com>

I mentioned the Small Business Association's free classes yesterday and
handed out an older calendar. Here is the newer calendar for those
interested in free classes to learn how to still do Python (and get paid) -
even if it isn't working for someone else.

To get a calendar regularly, send an email to Gary Marshall requesting this.
His email follows.

Cheers,


Glen

---------- Forwarded message ----------
From: Marshall, Gary N. <gary.marshall at sba.gov>
Date: Thu, Oct 28, 2010 at 5:05 PM
Subject: SBA Classes November 1 - 12
To: "Marshall, Gary N." <gary.marshall at sba.gov>


 If you do not wish to receive future announcements of SBA events, please
reply to this email with the word ?Delete? in the subject line.  Thank you.

******

*TRAINING AT SBA*

*****The Small Business Administration offers a variety of classes for
business owners in our Entrepreneur Center, located at 455 Market St., 6th
Floor in downtown San Francisco.*

*****Registration for all our classes is required.*

*To register for classes, go to*
*http://sbatraining.eventbrite.com/*<http://sbatraining.eventbrite.com/>

For more information, please contact Gary Marshall at (415) 744 6771 or
gary.marshall at sba.gov

******

*****The SBA training program is made possible by the generous support of
our volunteer teachers and presenters.   We appreciate their time and
expertise; however, these presentations do not represent an endorsement of
their views, opinions, products, or services by SBA.  All SBA programs are
extended to the public on a nondiscriminatory basis. Reasonable arrangements
for persons with disabilities will be made, if requested at least 2 weeks in
advance.  Contact: Gary Marshall at 415 744-6771.*

********

*****Food Safety Certification*******

11/1

8:30 AM - 5:00 PM

State law requires that specified food facilities employ at least one person
who has successfully passed a California State approved and accredited food
safety certification exam.  Certification is mandatory and re-certification
is required every three years.  Registration and information is available at
*www.ggra.org*

*****Restaurant Series:  Ten Proven Techniques for Restaurant Marketing & PR
*

11/1

2:30 PM - 4:30 PM

Learn 10 must-have tricks of the trade to market your restaurant and keep
customers coming back. Session includes instruction and round table
discussion to solve current marketing challenges.  $30 registration fee.
Presented by the SF SBDC.

*****State Labor Law and Payroll Tax*

11/2

9:00 AM - 3:00 PM

Jointly conducted by the Employment Development Department and the
California state Department of Labor Standards Enforcement, this class will
cover California recordkeeping and reporting requirements including employer
obligations and payment requirements; common wage and hour laws; employer
and employee rights and responsibilities.  More information at (866)
873-6083, register at *www.edd.ca.gov/taxsem*

*****Buying a Business*

11/2

6:00 PM ? 8:30 PM

This class will address the practical aspects of buying an existing
business, including how to locate companies for sale, assessing value,
negotiating the purchase and financing alternatives for an acquisition.
Additionally, you will learn about the ensuing ?due diligence process?,
related to the buyer?s examination of books, records, etc., after the
buyer/seller have agreed to price and terms.

*****Personal Branding*******

11/2

6:00 PM ? 8:30 PM

You can create a powerful personal brand that will position yourself as an
expert in your industry. Ryan will take you through his Holistic Personal
Branding system for clarifying your unique combination of strengths. This
self-knowledge will provide the foundation to create your authentic personal
brand.

*****Starting a Business in San Francisco*

11/3

10:30 AM - 12:00 PM

Hear directly from San Francisco officials.  How do you obtain permits?  How
do you register your business name? Learn what the City can do for you in
this one-stop seminar.

*****Financing Your Business*

11/3

1:00 PM - 3:00 PM

Discover the right way to seek financing for your business. We will discuss
loan proposal requirements, financing options and SBA programs.

*****Business Law Basics*

11/3

3:30 PM - 5:30 PM

An experienced business lawyer will discuss Choice of Legal Entity
(corporations, LLC, partnership, etc.); Intellectual Property; Employee
issues; and Real Estate issues.   This class does not constitute legal
advice.

*****How to Design and Deliver Effective Presentations*

11/3

6:00 PM ? 8:30 PM

Learn to present effectively and confidently, whether in front of small or
large groups.  Content and exercises include engaging your audience;
designing an effective presentation and conquering your fear of speaking.

*****Basic Bookkeeping, Part One*

11/4

1:00 PM - 4:00 PM

Topics include cash vs. accrual accounting, proper accounting data flow
processes, budgeting, the purpose of different financial reports, the
differences in computer accounting systems, cash management, and more.  $30
registration fee.  Presented by the SF SBDC.

*****E-Marketing in Spanish*

11/4

6:00 PM - 9:00 PM

Learn how to use the Internet to market your business.    This will be a
hands-on class (lap tops will be provided during class.)  Areas covered
include:  Website development and Social Media, Facebook for Businesses.
$ 10 registration fee. Presented by the SF Business Development Center.

*****Wholesaling Tips of the Trade*

11/4

6:00 PM - 8:30 PM

Learn the smart way to run a wholesale operation.  Areas covered include
industry information and networking, cost vs. price, channel conflicts,
branding and wholesaling online.  $30 registration fee. Presented by the SF
Business Development Center.

*******Restaurant Series: Customer Service ? Good is Minimum*

*******11/8*

*1:00 PM - 4:00 PM*

To make your restaurant a success you need employees who know how to use
customer service to increase sales. Effective, transparent up selling will
increase profits and keep your customers hungry for more. Learn how to hire,
motivate and train your employees to meet the service demands of the
industry.  We will cover the basic principles of customer service and
hospitality, server sequencing, suggestive selling techniques as well as
problem solving and how to handle difficult guests. $30 registration fee.
Presented by the SF SBDC.

******

*Integrated Sales and Marketing Excellence*

11/8

6:00 PM - 8:30 PM

Marketing?s job is to bring in the prospects. Sales? job is to close the
deal and book revenues. This class teaches you how to implement an
integrated sales and marketing system that work together to produce results.
Learn the quantitative marketing and sales methods that work in a down turn.

*****Writing Effective Business Plans        *

11/9

9:00 AM ? 4:00 PM

Whether you are planning to start a new business or developing the potential
of your existing company, a business plan is a critical foundation. In this
hands-on workshop, we will demystify the process using case studies and
exercises. You will also develop a template for your own business that
covers Products/Services; Organization; Marketing; Customers; Finances;
Market Research. Presented by SF SCORE.  Registration fee: $50.

*****Basic Bookkeeping, Part Two*

11/9

1:00 PM - 4:00 PM

We?ll cover balance sheets, incomes statements, cash flow and working
capital.  Participants should have completed Basic Bookkeeping, Part One, or
be familiar with the concepts covered in that seminar.  $30 registration
fee.  Presented by the SF SBDC.

*****Getting Your To-Do List Done*

11/9

6:00 PM - 8:30 PM

Do you have a To-Do list that never gets done? Do you have items on your
To-Do list that have been on there for days, weeks, even months? Do you
stress out thinking about how you?re going to get it all done? In this
course you will learn how to organize, prioritize and analyze your to-do
list so that you actually get it done.



*****Secrets to Buying and Selling a Business or Franchise*

11/9

6:30 PM?8:30 PM

Learn how to reduce your risk and improve your chances of success in buying
or selling a franchise or existing business. This workshop covers the steps
necessary for you to succeed working with professionals, and using simple
research and qualification techniques. Topics include Choosing the Right
Franchise or Business, Positioning Your Business for Sale, and Buyer and
Seller Financing.  Presented by SF SCORE.  Registration fee: $20.

*****Mobile Marketing and the Mobile Web *

11/10

6:00 PM ? 7:30 PM

Mobile Web use is exploding!  Blackberries, iPhones, and other always-online
devices are everywhere. Discover what you need to know about this exciting
new medium. You'll learn: critical factors your website must  have;
avoidable pitfalls that send customers running; understanding the vast sea
of handheld devices; tremendous mobile marketing opportunities; and low cost
ways to get started now.

******

*OUR PARTNERS PRESENT:*

a weekly feature of events offered by organizations and groups outside SBA.
 These events are not sponsored by SBA and are not held at our Entrepreneur
Center.

******

*Small Business Dialogue Group*

Who we are: 10-15 sole proprietors or small businesses owners with one
employee or less looking to grow and thrive in spite of a tough economy. We
are looking to share ideas, tackle challenges, problem solve and build
successful and profitable businesses. This is an opportunity to dispel any
feelings of professional isolation and to work with other small businesses
and entrepreneurs for mutual but independent gain.******



Each member of the group gets to be the 'Business of the Month' for one
session, during which the group hears about what they do, sell or serve.
We listen and assess the good and the bad, what is successful and what
is challenging. The entire group brainstorms and provides constructive
feedback on ways to improve the Business of the Month.



Guest speakers will be invited based on the needs of the group, and may
include:

     -A marketing expert

     -A financial/bookkeeping/QuickBooks expert

     -A successful business owner



When and where we meet: Second Wednesday of every month for two hours in
rotating San Francisco locations



More info: Ellen Shershow Pe?a,
*thatgirl at ellenswebsite.com*<thatgirl at ellenswebsite.com>or
415.690.0278

******

*Where's the Money? 2nd Annual Access to Capital Business Expo*

Saturday, November 6, 2010

8am - 2:30pm ? Hyatt Regency

Five Embarcadero Center, San Francisco, CA 94111

Includes: Breakfast?Expo?Lunch?

Workshops?One on One Consultation

$10 registration fee.

Online: *www.vedc.org* <http://www.vedc.org>

Phone: (415) 541-8580

E-mail: *info at rencenter.org* <info at rencenter.org>******

******

Our mailing address:

Small Business Administration

455 Market St., 6th floor

San Francisco CA 94105

 thanks,

Gary

Gary Marshall

SBA Business Development Specialist

415 744 6771




-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101029/863a48e5/attachment-0001.html>

From glen at glenjarvis.com  Sat Oct 30 05:33:48 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Fri, 29 Oct 2010 20:33:48 -0700
Subject: [Baypiggies] Slides and Handouts
Message-ID: <AANLkTimR1T0LhLHY4jYQVjEfq-SiXGD=b_JURyRf2kZF@mail.gmail.com>

Here are the slides and handouts that I had given at last night's talk.

I substituted a new calendar (starting 1-Nov) for the older calendar that I
distributed last night.

Plain, but functional:

http://glenjarvis.com/baypiggies/

Cheers,


Glen
-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101029/bd8e67b6/attachment.html>

From spmcinerney at hotmail.com  Sat Oct 30 12:13:55 2010
From: spmcinerney at hotmail.com (Stephen McInerney)
Date: Sat, 30 Oct 2010 03:13:55 -0700
Subject: [Baypiggies] Consulting As a Career Choice / advice on using eLance
Message-ID: <BLU0-SMTP12491832C0E022D06707353A0460@phx.gbl>


Any advice from the pros on how to use eLance.com, do's/don'ts, how to 
tell a good or bad client or job, etc.?
(or Craigslist Gigs for that matter)
(as mentioned by Glen several times at Thursday's talk)

Thanks again to Glen, Annette, Monte and Emile for very useful talks.

Regards,
Stephen

From glen at glenjarvis.com  Sat Oct 30 17:10:59 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Sat, 30 Oct 2010 08:10:59 -0700
Subject: [Baypiggies] Consulting As a Career Choice / advice on using
	eLance
In-Reply-To: <BLU0-SMTP12491832C0E022D06707353A0460@phx.gbl>
References: <BLU0-SMTP12491832C0E022D06707353A0460@phx.gbl>
Message-ID: <5AA214B9-1D24-4CF8-8910-1A796E8A0CD5@glenjarvis.com>

I'm about to attend a class for the next 9 hours (Kirk McKusick's FreeBSD internals course ROCKS).

After that, I'll put together a write up on this and send out. I find it a good way to get an itsy bitsy project under one's belt and determine if one  is even interested in doing Python contracting.

Glen

El Oct 30, 2010, a las 3:13 AM, Stephen McInerney <spmcinerney at hotmail.com> escribi?:

> 
> Any advice from the pros on how to use eLance.com, do's/don'ts, how to tell a good or bad client or job, etc.?
> (or Craigslist Gigs for that matter)
> (as mentioned by Glen several times at Thursday's talk)
> 
> Thanks again to Glen, Annette, Monte and Emile for very useful talks.
> 
> Regards,
> Stephen
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies

From glen at glenjarvis.com  Sun Oct 31 20:34:11 2010
From: glen at glenjarvis.com (Glen Jarvis)
Date: Sun, 31 Oct 2010 12:34:11 -0700
Subject: [Baypiggies] Consulting As a Career Choice / advice on using
	eLance
In-Reply-To: <BLU0-SMTP12491832C0E022D06707353A0460@phx.gbl>
References: <BLU0-SMTP12491832C0E022D06707353A0460@phx.gbl>
Message-ID: <AANLkTikQobfzAz3EV8fTSV9KRbsA=52FH8ADOfiwBBRQ@mail.gmail.com>

On Sat, Oct 30, 2010 at 3:13 AM, Stephen McInerney
<spmcinerney at hotmail.com>wrote:

> Any advice from the pros on how to use eLance.com, do's/don'ts, how to tell
> a good or bad client or job, etc.?
> (or Craigslist Gigs for that matter)
> (as mentioned by Glen several times at Thursday's talk)
>


I don't know if I'm a "pro" or not. I do know that I was able to survive for
a year (without a start up savings account) by doing only python work --
when I had only learned Python a half a year before.

With that said, I took a lot of jobs that weren't ideal, I worked hard long
hours, I took international calls at 3 am, I worried a lot, etc. So, it
wasn't easy and certainly wasn't always ideal. It did keep me professionally
in Python, however (and THAT part was ideal). I also learned a *lot* -- it
was a great way to have "on the job" training on topics I wanted to learn.
I, of course, didn't charge my customers for the time I spent learning a
piece of technology that they needed in their puzzle that I didn't yet know.
And, I avoided projects where I didn't already know a good chunk of what
they needed.

It's amazing how much of your time is spent actually looking for work,
reviewing the websites, talking to people, etc. A lot of the time, people
wanted advice on how to get a website working. I would talk to them, explain
what I knew, and often explain what I didn't know (and instead referred them
to someone else). One could say that I "wasted" a lot of time by listening
to the clients for free and referring them to someone else. But, after a
while, I built up a relationship with the customers so that they knew they
could trust me. And, that led to a lot of good repeat work.

I hadn't done any contracting for about six months because my current job is
just too demanding. And, the contracting I've been doing the past year and a
half was away from elance. So, the website has changed a bit since I was
last on it.

I reviewed my Elance profile this morning and am looking at it now.

Here are some bullet points of what I'd be careful about:

* Look for projects that have several well defined milestones. I'd much
rather take a project with a bunch of small milestones than a project with
only one milestone. The milestones are a good check-point along the way (for
both sides).

* Pick milestones that appear realistic when it comes to the amount of time
it would take to complete. Even for, by the hour projects, these things are
estimated on how long they will take. Pick something that you think is
realistic and avoid any headaches for your first project. If someone wants a
web page that is a "competitor to Google" and they fund a milestone of $500
(or 5 hours) for the search engine, avoid that job like the plague.

* Don't start work until the customer funds the milestone in question. The
customer pays elance for the milestone before work starts -- so you know the
money is available. You don't get the money, however, until you've delivered
on the milestone and the customer clicks a link to release the money from
escrow. The customer can't get the money back once they have funded the
milestone -- they can refuse to release the money to you, however, if you
haven't delivered on what was stated. Elance can arbitrate -- so keep clear
communication and good records.

* Avoid projects that are fixed-billing/flat rate. Although there are
*wonderful* reasons for choosing a fixed-rate project, there are some pretty
big gotchas. Until you've build the experience and confidence of working on
such things, keep it simpler and pick jobs that are paid by the hour.

* Check a customer's past rating. Elance is like Ebay. I wouldn't buy
something big from Ebay if that person didn't have a really good rating from
other buyers. Likewise, I wouldn't take a job from someone who has a poor
evaluation. I'd also check out how that customer evaluated other jobs. This
will tell you how easy/hard they are to work for and what are the important
issues for them.

* Look at how much money the customer has paid other clients. If they've
paid other people for other jobs, chances are very high that they'll pay you
if you deliver what you promised to deliver.

* Use the elance escrow service. Sure, they will take a portion of what
you're paid from the job. However, you're guaranteed to get paid if you
follow their rules. Elance will cover the debt themselves if you follow the
rules.

* I'd pick a tiny (itsy bitsy) job for the very first project. You're
probably not going to make a million working with Elance customers. But,
it's a great way to see if this is even what you want to do. Picking a small
project, and delivering on it, helps to build your ratings. You have a
smaller risk on a project that only pays $500 than you would for a very
large project. If you want out, finish the $500 project and you're done.
Large projects take a lot more time and you can feel trapped.

* Use a contract when you negotiate the deal. I use a boiler-plate contract
that I downloaded from the IRS. It works wonderfully and makes certain
everyone agrees on the amount of work that needs done.

* Take the free Elance Python tests so you can demonstrate your skills to
your customers. It also doesn't hurt to have a portfolio of previous
customers. If you're trying to build that portfolio, do small projects and
work cheaply -- what you're building here is a customer base, good reviews,
and a portfolio. That's a great investment for future work.

Let's take the above and look a concrete example (it's still open for
bidding):

Job: Python PS3 Theme Compiler
Link: http://www.elance.com/j/python-ps3-theme-compiler/21727078/
Budget: Less than $500

Do you already know what a Playstation 3 Theme files (.P3T) looks like? Are
you interested in learning regardless -- even if it costs you some time?

That is the main thrust of this tiny job. I'd normally be wary of the fact
that this is a fixed budget job. However, if I already knew the above format
(.P3T), this is a small enough job it trumps most of the concerns I had
about milestones and fixed-budget jobs. With that said, if I don't already
know the format (as I personally don't), I'd be very careful
about committing to this as a fixed-fee. Maybe this is a *lot* harder than
it looks and $500 is crazy cheap to do the work in question (maybe it's a
binary format you have to reverse engineer). If this is harder than the
customer thinks, you may explain that to them and say that you're willing to
work on it on an hourly basis. This can be negotiated up front before
any commitments are made.

I'd also be careful about this job because the customer doesn't have any
history of hiring jobs. It's small enough, however, that the risk can be
minimized. You don't know how they'll rate you, and reputation is uber
important here, so give them great service!

The competition that's bidding on this job looks like they know what they're
doing:

http://www.elance.com/e/srcoley/

His python skill set (from the test) is above average. He has a five star
review (but has only been reviewed once), and he has earned about $10K
through elance. He has bid on the job, so he may well get it.

In summary, I'd say it all comes down to how comfortable you are with the
.P3T file format and the python you'd need to do this job. If you are very
comfortable, there's little to risk by bidding on this job if you can do it
in a reasonable amount of time.


Hopefully this helps answer your questions. There are other sites than just
elance. There's guru.com and many others.  It all comes down to how hard
you're will to hustle to get work and grow your skills. Also, if you can
keep great relationships with your customers, you can get more work through
referrals than you can keep up with, although that will take time...


Cheers,


Glen
-- 
Whatever you can do or imagine, begin it;
boldness has beauty, magic, and power in it.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101031/5884b366/attachment.html>