Re: Building Binary Packages

[Jim B. Wilson]

On Wed, 10 Oct 2007 14:35:35 +, kyosohma wrote:

> I am trying to figure out how to build binaries for Python packages and
> I've done it with MinGW. 

Apparently, you still can: http://tinyurl.com/yb4bps
-- 
http://mail.python.org/mailman/listinfo/python-list

The curious behavior of integer objects

[Jim B. Wilson]

Am I nuts? Or only profoundly confused? I expected the this little script
to print "0":

class foo(int): 
  def __init__(self, value):
self = value & 0xF

print foo(0x10)

Instead, it prints "16" (at least on python 2.4.4 (Linux) and 2.5 (Wine).

Jim Wilson
GNV, FL
-- 
http://mail.python.org/mailman/listinfo/python-list

Debugging pipe IPC

[Jim B. Wilson]

I have the mother (of all) application(s, written in C++) that 
occasionally outsources certain tasks to a child Python script.  The 
mother fork/execs (or equivalent) the child and then begins serving the 
child's requests.

The child/client sends requests on its stdout and receives responses on 
stdin.  The interaction is facilitated by a Pyrex extension which handles 
the lower-level aspects of the conversation and exposes a few functions 
and classes to the script.

This part works peachy keen, but debugging has so far been via 
print>>stderr-and-scratch-head.

On a contemplative bike ride one day, I imagined how neat it would be to 
run interactively.  On returning, I began to experiment with rebinding 
sys.stdin and sys.stdout to /dev/tty, using the "-i" command-line switch, 
etc. to see if I could devise a child that prompted me with ">>>" and 
allowed me to compose/test small snippets on the terminal.  So far, no 
joy.

Is this possible?  If so, can someone nudge me toward a solution or 
better yet a recipe?

Jim Wilson
Gainesville, FL





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

Re: Debugging pipe IPC

[Jim B. Wilson]

Ian Clark pointed me to:

> ... the cmd module. 
> 

Yes, I found that, but I could only get it to print a nice interactive 
prompt, "(Cmd)", read a line of input and discard it.  Apparently, I'm 
too stupid to figure out how to hook it into python.

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

Re: Another newbie design question

[Jim B. Wilson]

[EMAIL PROTECTED] wrote:

> If you can only [block comments] or [multi-line strings] the other,
> which is more helpful?

I'm afraid no one would use a language that didn't feature block 
comments.  However, inspection of a vast corpus of code might lead one 
to believe that any commenting capability was completely unnecessary.

> Should I have both? (Make a strong argument here: my design principal
>  is, "Designed by a backpacker: when in doubt, leave it out.")

After my brief experience with Python, I don't think I'd advocate the 
removal of """'d strings.  They come in quite handy in a lot of 
practical cases.

And remember: "If you need it and you don't have it, you don't need it."
(at least in backpacking :)

Jim Wilson
Gainesville, FL

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

Re: Debugging pipe IPC

[Jim B. Wilson]

Ian Clark wrote:
> Jim B. Wilson wrote:
> ...
>> The child/client sends requests on its stdout and receives responses 
>> on stdin.
> 
> So, why can't you just run this client on the command line and let the 
> shell handle stdin/stdout for you?

I'm not sure I understand the topology of your proposal?  And, it's 
certainly possible the shell has mystical powers of which I am unaware.

Are you suggesting a run client that spews the mother's messages to the 
terminal, and I somehow cut/paste them into the client, running with 
stdin/stdout unconnected to anything but me?  Or is there some 
combination of tee, etal.,  I can lash together so that my commands (to 
the client) don't get mixed up with mother's messages?

Some such arrangement would surely help.  I often forget the ">>stderr," 
on my scratch-head debugging prints, and mother gets quite upset when 
the incoming message doesn't fit the mold :)

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

Re: Debugging pipe IPC

[Jim B. Wilson]

Ian Clark wrote:

> ... whatever 'mother' was sending it ("Clean your room!" most like)

:)

> If it's very verbose ...

Alas, it is quite verbose.  Constructing a single instance of a class
(from the Pyrex extension acting as the child's two-way radio) could
involve tens of thousands of more-or-less random exchanges between
mother and child.  A subsequent method call could trigger a similar
volume of traffic.

And it isn't this communication I'm worried about.  All that seems to go
quite well.  My fondest wish is to play the role of the child at the
good old ">>>" prompt.  Such play would allow me to test tiny snippets
of code that I could later incorporate into an actual child.

My wish may not be possible.  If so, it's no great tragedy.  A simple
test goes from:

>>> foo = askmommy()
>>> foo.why()

to:

   1. Typing similar statements into my editor.
   2. Saving these statements to a file, say "test.py".
   3. Making clicky-clicky in the mother application to run "test.py".
   4. Noticing that nothing appears on my terminal.
   5. Inserting ">>sys.stderr," into "print foo.why()" :)
   6. Repeating steps 2 and 3.

Steps 4, 5 and 6 are required because the mother has absolutely no
compunction against infanticide when her child asks her a question she
cannot answer.

If my wish isn't possible, it will be the first time.  Normally, when I
wonder if Python can do something, I imagine what the syntax would be if
it could, type it in, and sure enough it works.

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

Re: Debugging pipe IPC

[Jim B. Wilson]

Ian Clark wrote:

 > import os
 > os.system("netcat -l -p 1234 localhost")
 >
 > HTH,

Nope, but the network theme got me thinking about how one might run 
Python on a remote host.  After a few false starts, Googling "remote 
python shell" led me to Guido's "ripshell.py" (not *that* Guido, a 
different one).  Peeking inside, I discovered the module I'm looking for 
was "code".  Remember, in my case, communication on stdin and stdout
was all handled by a Pyrex extension.  I'm unsure the code below will 
work in a pure Python application.

For posterity, here is itest.py, the solution to my problem:

### itest.py - allows interactive debugging of a "filter"
#
#  If stdin and stdout are dedicated to your filter script, but you
#  want to interactively check a few things, try something like this:

from code import interact
import sys

sys.stdout = open("/dev/tty", "w")  # Rebind Python's lips
sys.stdin  = open("/dev/tty", "r")  #  and Python's ears.

foo = "This is a test"  # Lay down some history
interact(   # Convenience function from code.
   "At your service, Sir!", #   BUG: could be "Madam" or "Miss"
   local = locals())#   Teach interpreter some history
print "Thank you, Sir!" # BUG: ibid.

To check this works:

$ python itest.py /dev/full # mother is a deafmute
At your service, Sir!
 >>> foo
'This is a test'
 >>> ^D (not shown)
Thank you, Sir!
$
-- 
http://mail.python.org/mailman/listinfo/python-list