Re: List sequential initialization

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 HMS Surprise <[EMAIL PROTECTED]> wrote:

> I thought if I could do this:
> >>> a = b = ''

a and b refer to the same object (the empty string)

> >>> a = 'a'

You are assigning a new value to a - it now refers to the string 'a', 
while b refers to the same thing it always has (the empty string)

> >>> a
> 'a'
> >>> b
> ''
> 
> then this would behave similarly:
> >>> la = lb = []

la and lb refer to the same object, an empty list

> >>> la.append('a')

You are appending 'a' to the list that la refers to.

> >>> la
> ['a']
> >>> lb
> ['a']

Since lb referred to the same list as la, when you modified the list via 
la.append, those changes can also be seen via lb.

If instead of la.append('a'), you had done:

la = ['a']

Then it would have behaved similarly to the first example, and lb would 
still refer to an empty list.

> 
> I thought wrong! But don't know why.

For immutable objects (such as integers, strings, and tuples), the 
distinction between pointing to the same object or identical copies 
isn't important since you cannot modify the objects.  However, when you 
use mutable objects (such as lists) and modify them, then it is 
important to understand when you are dealing with the same object and 
when you are copying the object.  

Assignment makes a name refer to an object.  Multiple names can refer to 
the same object (which is what a=b=c does).  If you want to make a copy 
of the object, you need to do so explicitly:

>>> a = [1, 2, 3]
>>> b = list(a)
>>> a.append(4)
>>> a
[1, 2, 3, 4]
>>> b
[1, 2, 3]


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

Re: PEP 3107 and stronger typing (note: probably a newbie question)

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 kaens <[EMAIL PROTECTED]> wrote:

> On 6/20/07, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> 
> > That is exactly the problem - there is no "some more" static typing.
> > There is static typing - or not. You can't have it "just a bit".
> 
> Couldn't a language be made so that if you declared a variable like, say:
> 
> string foo = "I'm a string"
> 
> it would be a string, and always a string, and if you declared a variable like
> 
> foo = "i'm a dynamic variable"
> 
> it would be considered dynamic?
> 
> This doesn't seem like it would be too hard to add in to a language
> that already had dynamic typing (But then again, I am inexperienced -
> although interested in - language design).
> 
> It seems to me like this could be really useful, but I'm not aware of
> any language implementing something like this.

Common Lisp has a mechanism similar to what you described.  In general, 
variables are completely dynamic.  However, it is possible to declare 
individual variables to be of specific types.  There are also 
declarations that allow you to specify your preferences for speed versus 
safety.  The upshot of all of this is that the language is a dynamic 
language most of the time, but the programmer can choose to give the 
compiler a bit more information, and with that information a good 
compiler can generate more efficient code (often competitive with the 
speed of C code).

The Common Lisp approach is not without its problems (for one thing, a 
lot of the behavior when type declarations are not met is implementation 
dependent).  But I think there are some ideas in there that could be 
applied to Python.

On the other hand, I'm pretty happy with Python/SWIG/C++ for performance 
critical code, so I'm not sure if optional static typing would really be 
of much use unless the Python compiler got *very* good at generating 
optimized code when declarations were present.

I still think it would be handy to easily specify the expected types of 
function arguments.  I sometimes write code in this pattern:

def foo(a, b):
"a, b - instances of Bar"
assert isinstance(a, Bar)
assert isinstance(b, Bar)
# do some stuff

Note that the expectation that 'a' and 'b' are to be of type Bar is 
specified twice: once for a runtime check, once for the docstring.  It 
might be nice if there were a mechanism to specify it once and have the 
docstring and runtime check both make use of that information:

>>>def foo(Bar a, Bar b):
>>># do some stuff

>>>foo(1, Bar())
TypeError: argument a is not of type Bar

>>>help(foo)
foo(Bar a, Bar b)

On the downside, this sort of mechanism might do more harm than good.  
For one thing, it would really clash with duck typing.  For another, 
anyone coming to Python from Java/C++ would probably use those 
declarations *everywhere*, even when there isn't a good reason to limit 
the type.

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

Re: "assert" annoyance

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 Paul Rubin  wrote:

> 
> What I really want is for any assertion failure, anywhere in the
> program, to trap to the debugger WITHOUT blowing out of the scope
> where the failure happened, so I can examine the local frame.  That
> just seems natural, but I don't see an obvious way to do it.  Am I
> missing something?  I guess I could replace all the assertions with
> function calls that launch pdb, but why bother having an assert
> statement?

I tend to run my programs with a -i option:

python -i foo.py

Then if an exception occurs, I can do:

import pdb
pdm.pm()

and have a debug session at the point where the exception was raised.  
The "-i" shouldn't interfere with sys.argv since it is before the python 
file.

Another option would be for your program to do something like:

try:
# put your code here
except:
import sys
import pdb
pdb.post_mortem(sys.exc_info()[2])


If an exception is raised, the debugger will be started using the 
appropriate traceback.  (You don't need to import sys and pdb in the 
except block if they have already been imported.)


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

Re: Tuple vs List: Whats the difference?

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 Shafik <[EMAIL PROTECTED]> wrote:

> Hello folks,
> 
> I am an experienced programmer, but very new to python (2 days). I
> wanted to ask: what exactly is the difference between a tuple and a
> list? I'm sure there are some, but I can't seem to find a situation
> where I can use one but not the other.

Lists and tuples are both sequences, and can be used interchangeably in 
many situations.  The big difference is that lists are mutable (can be 
modified), and tuples are immutable (cannot be modified).  Lists also 
have a richer API (for example the index and count methods).

If you are going to need to change the contents of the sequence 
(appending, removing, altering a value, etc), then use a list.

If you require the sequence to be immutable (such as being used as the 
key in a dictionary), then use a tuple.

In general, tuples should be a little more efficient than lists.  
However, altering a list is more efficient than creating a new tuple, so 
"always prefer tuples" does not necessarily lead to a faster overall 
program.  Unless performance is critical, I wouldn't worry about this 
factor.

IMHO, a more important reason to prefer tuples is that since they are 
immutable, you don't have to worry about side effects.  If you call a 
function and pass it a list, you have no guarantee that the list won't 
be changed during the function call.  With tuples, any attempt to change 
the tuple will raise an exception.  If it is important to the caller 
that the sequence remain unchanged, then a tuple is a safer 
representation for that sequence.

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

Re: Function parameter type safety?

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 Robert Dailey <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> Is there a way to force a specific parameter in a function to be a
> specific type? For example, say the first parameter in a function of
> mine is required to be a string. If the user passes in an integer, I
> want to notify them that they should pass in a string, not an integer.

At present, there isn't any built-in way to do this (see the recent 
thread "PEP 3107 and stronger typing" for a long discussion).

However, you can use assert and isinstance() to check it manually:

def foo(a):
   assert isinstance(a, str), "argument 'a' must be a string"


I wouldn't advocate getting carried away with this pattern since it 
precludes your function from working with duck typing and defeats some 
of the dynamic nature of Python.  On the other hand, without such checks 
the resulting exceptions from assuming an argument is one type when it 
is another can be a bit misleading.

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

Re: Can a low-level programmer learn OOP?

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 Chris Carlen <[EMAIL PROTECTED]> wrote:

> Why would OOP be better?  Different is not better.  Popular is not 
> better.  What the academics say is not better.  Less lines of code might 
> be better, if the priority is ease of programming.  Or, less machine 
> execution time or memory usage might be better, if that is the priority.

Short answer: Increasing programmer productivity is better, and OO 
frequently accomplishes this.

Longer answer:

Consider OOP as one tool in the toolbox.  It isn't "best" for every 
conceivable problem, but neither is procedural programming, functional 
programming, table driven state machines, or any other style of design 
and/or programming.  Each works well in some situations and poorly in 
others.  Having a large number of tools at your disposal, and knowing 
which ones to use, is a big plus.

Let's talk about design versus implementation for a moment, since OO 
really applies to both, but in different ways.  You mentioned state 
machines, and that is a good example of a design technique.  You can 
look at a problem and convert it to a state machine (design), then 
implement the state machine in whatever language your computer 
understands.  Over the years, finite state machines have proven to be 
very effective models because:

1) there are plenty of real world problems that map cleanly to a state 
machine

2) state machines are easy to implement reliably in most computer 
languages

3) if you have already implemented a state machine for problem A, then 
implementing it for problem B is pretty easy - the real work is 
translating problem B into a state machine

OOD is similar.  There are a large number of problems for which an 
object oriented design is a good fit.  Once you have an OO design, you 
then need to implement it, and languages with good OO support make this 
a lot easier.

>From what I have seen, the advantages of OO tend to increase with the 
size of the project.  For example, polymorphism generally lets M clients 
work with N different kinds of objects by writing M+N chunks of code 
rather than M*N.  When M or N is small, this difference in minor, but as 
M and N increase, it becomes significant.

By combining state and function, objects provide a good means of 
encapsulating operations and keeping client code independent of lower 
level code.  This is a very big win since it allows for the evolution of 
the lower level code without breaking all of the client code.  As with 
polymorphism, the benefits of encapsulation tend to increase with the 
size of the project.

Even before OO languages were popular, it was quite common to use some 
basic OO design in order to increase encapsulation.  If you look at 
almost any GUI framework from the 80's or early 90's you'll find lots of 
C code with structs that the user is not supposed to mess with, and then 
functions that take pointers/handles/indexes to those "magic" structs as 
the first argument.  This is really OO design implemented in a 
procedural language.  In fact, GUI frameworks are an excellent example 
of a domain for which OO has established itself a very good way to model 
the problem.

I could probably spend a lot more time on the merits of OO, but I think 
if you really want to understand its benefits you need to work with it 
in a domain for which OO is useful.  It is possible that the specific 
projects you work on really wouldn't benefit much from OO, and that is 
why you haven't had the "a-ha!" moment.  Forcing an OO model onto a 
problem just for the sake of OO will only result in frustration.

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

Re: Discover instance variables

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 JonathanB <[EMAIL PROTECTED]> wrote:

> I can handle the formatting and changing the variable itself, no
> problem, but how do I get a list of all the variables in a class
> instance? I almost put a list in there called vars and appended all
> the variables to it so I could iterate the list, but this sounds like
> something useful enough that someone has come up with a better way to
> do it than that. It almost looks like self.__dir__() is what I want,
> but that returns methods as well, correct? I only want variables, but
> I can't think of how to do a list comprehension that would remove the
> methods.

For simple cases, the object's __dict__ will probably give you what you 
want.  By default, that's where an object's instance variables are 
stored, and you can just examine the keys, etc:

class Foo(object):
 def __init__(self):
 self.a = "bar"
 self.z = "test"
 self.var = 2
 
foo = Foo()
print foo.__dict__

-> {'a': 'bar', 'var': 2, 'z': 'test'}

However, there are lots of ways to bypass using the __dict__ to hold 
attributes.  If the class uses any of these techniques, __dict__ either 
will not exist or may not be complete.  A few of the techniques that 
come to mind are:

* custom __getattr__/__setattr__ methods (or __getattribute__ in a new 
style class)

* descriptors (http://docs.python.org/ref/descriptors.html)

* using __slots__ in a new style class


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

Re: Simulating simple electric circuits

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 Bjoern Schliessmann <[EMAIL PROTECTED]> 
 wrote:

> Hello all,
> 
> I'm trying to simulate simple electric logic (asynchronous)
> circuits. By "simple" I mean that I only want to know if I
> have "current" or "no current" (it's quite digital) and the only
> elements need to be (with some level of abstraction to my specific
> problem)
> 
> - sources (here begin currents)
> - ground (here end currents)
> - joints
> - switches (which are able to let current pass or not, depending on
>   outside influence)
> - loads (which can signal change in current flow to the outside --
>   just like a light bulb)

Are you trying to do logic simulation (digital) or analog circuit 
simulation?  The only reason I ask is that the simulation techniques are 
very different, and you used both "logic" and "current" in your 
description, so I'm not quite sure which direction you are heading.


For analog:

If you are ignoring time related effects (no inductance or capacitance), 
then the system is solvable as a set of linear equations.  Basically 
your circuit consists of a set of nodes and edges.  Wires are edges, 
joints are nodes.  An open switch is nothing, a closed switch is an 
edge.  A load is an edge.  You'll have to assign resistances to the 
edges (anything non-zero will do) in order for the equations to make 
sense.  Then you can use Kirchoff's laws to analyze the circuit and 
construct the equations to solve.  A good linear algebra library (numpy) 
will help in solving the equations.  

Opening or closing a switch would result in a new set of equations, and 
thus a new solution.  You might be able to get clever and model open 
switches as edges with infinite resistance, which would allow you to 
skip the Kirchoff stuff each time a switch is flipped.  You'd only have 
to change coefficients and solve the system of equations.  However, the 
system of equations would be singular, so you'd have to do something 
like an SVD rather than an inverse.

I don't want to go into too much more detail about this one because I 
have a hunch you are really looking at digital, but if you're interested 
in the analog approach let me know and I'll fill in more of the details.


For digital:

Event based simulation is typical here.  These simulations generally are 
concerned with voltage, not current.  A circuit consists of signals and 
devices.  At any given time, each signal has a certain state (high/low, 
on/off, 9 level logic, whatever).  Devices are connected to one another 
by signals.  You'll also need events (a signal, a time, and a new 
state), and an event queue (events sorted by time).  This is easier if 
each signal is driven by at most one device:

1) pop the next event off the queue
2) if the event's signal's state is the same as the new state, go to 1
3) set the event's signal's state to the new state
4) for each device that is attached to the signal, run the device's 
code, which should look at all of its inputs, and post new events to the 
queue for any outputs (do this even if the computed output is the same 
as the current output).  These events are usually posted for some time 
in the future (1 simulation 'tick' is fine).
5) go to 1

This approach is pretty simple to do in Python.  I wrote a sample 
digital simulator a while back and the core of the simulator was around 
50 lines of code.  Rounded out with some basic logic gates and helper 
functions to probe the simulation, it was around 150 lines.  It was only 
2 level logic and signals could only be driven by a single device.

The devices that you want to model (switches, loads, etc) don't have 
explicit inputs and outputs, and you'll need to deal with a signal being 
driven from multiple sources, so it will get a bit more complicated.  
You will probably also need 9 level logic (or something equivalent) to 
deal with the fact that ground beats a source through a load when 
determining a node's state.

The basic idea is that each signal has multiple drivers, each of which 
has an internal state.  When a device wants to set an output, it only 
changes its driver's state.  The signal then has code that looks at the 
state of all drivers and combines them in some way (this is called a 
resolution function).  That combined state is what devices see when they 
read the signal.

It isn't *that* complicated to implement, but if you can turn your 
problem into one with 2 level logic and no multiple drivers, then it 
will be easier to write and debug.

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

Re: Simulating simple electric circuits

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 Bjoern Schliessmann <[EMAIL PROTECTED]> 
 wrote:

> Sounds more familiar than the analog approach. Maybe I misunderstood
> something ... but I can't transfer my problem to this way of
> thinking yet. My biggest problem is the fact that relays aren't
> really interested in voltage, but current. 
> 
> Also, I find it difficult to transfer this circuit logic to boolean
> logic I can contruct logic gates from. Sometimes, electric circuits
> are used in different directions.

Yep, the traditional digital simulation techniques don't apply very well 
to things like switches and relays.  Going with a different approach is 
probably cleaner.

> 
> I set up the mentioned "controller" which, at the beginning, tries
> out all possible ways through the network and saves them. So, for
> every possible circuit it knows which switches must be closed and
> which relays will work if it's "on". In theory, it should now be
> possible to try out every path, tell the relays if they have
> voltage/current, and let the relays report back in to the
> controller if their status changes so it can again test the
> circuits that may have changed. I haven't tried out the last step,
> but I will in the next days. Is there any logic error in my
> strategy?

Sounds reasonable.  Depending on the size of your network, I might not 
worry too much about precomputing and saving information.  If your 
circuit has loops in it (where the output of a later relay circles back 
to an earlier relay's coil), then it is possible for the circuit to 
oscillate, so you might have to be careful about this.  For example, if 
your basic simulation flow was:

1) set initial conditions (switches, etc)
2) let power flow through the system
3) determine which relays will be thrown
4) if any relays have changed state, go to 2

Then an oscillating circuit would never quit.  You might want to put a 
limit on the number of iterations through the loop, or logic that 
explicitly checks for oscillation.  Or you could analyze the circuit 
ahead of time to see whether it has oscillation or not.

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

Re: newb: Python Module and Class Scope

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 johnny <[EMAIL PROTECTED]> wrote:

> Can a class inside a module, access a method, outside of class, but
> inside of the module?
> 
> Eg.  Can instance of class a access main, if so how?  What is the
> scope of "def main()" interms of class A?
> 
> myModule:
> 
> class A:
>main()
> 
> def main():
> 

Yes, class A can access main.  The name "main" will be defined at the 
top level of the module, and is considered a global for that module.  
Code within that module can access it simply as "main".  Code in other 
modules would have to import the module in order to use symbols within 
it.  For example...

### myModule.py 

class A:
  def m():
main()

def main():
  pass


### other.py ###

import myModule

def main():
  pass

class B:
  def o():
main() # calls main() in this module
myModule.main() # calls main in myModule



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

Re: A few questions

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 jay <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I'm totally new to Python and was hoping someone might be able to  
> answer a few questions for me:
> 
> 1.  What are your views about Python vs Perl?  Do you see one as  
> better than the other?

I introduced Python into my group at work and it has for the most part 
supplanted Perl.  For short scripts Python tends to be a lot more 
readable than Perl.  Python also scales better, allowing us to tackle 
some larger projects with Python than we would have attempted with Perl.
 
However, a lot of this depends on your current skill with the languages 
and the kind of project you will be working on.  A Perl guru is going to 
be more productive with Perl than with Python.  Text processing programs 
are likely to be more concise in Perl than Python.  However, as a 
general purpose programming language I think Python is an excellent 
choice.

> 2.  Is there a good book to start with while learning Python?  I'm  
> currently reading 'Python Essential Reference' by David M. Beazley.   
> So far it looks like a pretty good book, but would like more  
> tutorials to work with (I've also been reading through the tutorials  
> at 'python.org' which has some excellent stuff!).

"Learning Python" is a good book for getting started, although it is a 
bit dated by now.  It might not be quite what you are looking for with 
respect to tutorials, so I'd recommend looking at a copy before buying 
it.

> 3.  Currently, I write most of my code with Xcode (on the Mac  
> platform) using Applescript.  This gives me GUI capabilities.  Is  
> there anything you'd recommend that I could use for Python that would  
> give me a GUI interface?  I'd like this to be able to work for both  
> the Mac and Windows platforms.  I've been reading a little about  
> 'Claro Graphics Toolkit' and 'PyGUI'... would you recommend either of  
> those?  I'll be writing code on a Mac so I need something that will  
> run on that system.

Tkinter is the easiest way to get started with Python GUI programming 
because it is part of the default python distribution.  However, I 
prefer wxPython for GUI development.  You'll have to install a few extra 
pieces, but in the end wxPython does a better job of being "pythonic" 
for the programmer, and resulting in native look and feel for the user.  
"wxPython in Action" is an excellent book for learning about wxPython.


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

Re: What is an instance and what isn't?

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 "Gre7g Luterman" <[EMAIL PROTECTED]> wrote:

> I suppose I was lulled into complacency by how Python makes so many things 
> look like classes, but I'm starting to realize that they're not, are they?
> 
> I'm writing a C program which handles Python objects in different ways based 
> on their type. I do a PyInstance_Check(PyObj) to determine if the PyObj is 
> an instance, but it is returning 0 on a lot of stuff that I thought would be 
> an instance. So I did the following simple test on three things that look 
> like instances:
> 
> Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] 
> on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class a: pass
> ...
> >>> type(a())
> 
> >>> type(Exception())
> 
> >>> class b(dict): pass
> ...
> >>> type(b())
> 
> 
> I was relieved that a() returns an instance, but I was surprised that 
> Exceptions aren't really instances at all. And what's the deal with derving 
> a class from a standard type like a dictionary? I thought for sure, that 
> would be an instance, but this shows it is a class?!?
> 


There are actually two kinds of classes in Python (as of 2.2): new-style 
classes and classic classes.  What you are calling an instance is an 
instance of a classic class.  Here is how a new-style class would look:

>>> class c(object): pass
... 
>>> type(c())


Actually the new-style classes are a lot more consistent with the 
built-in types, and the type hierarchy makes more sense with them, so I 
would suggest in general migrating towards new-style classes for all of 
your own code.

More information about new-style classes can be found here: 
http://docs.python.org/ref/node33.html
http://www.python.org/doc/newstyle.html

> Can anyone explain the last one and/or give me a simple test I can do in C 
> to determine whether a Python object is "instance-like"?

With new-style classes, the type of an instance of that class is the 
class itself (type(x) == x.__class__).  In your above example, class b 
is a subclass of dict, which itself is a new-style class, making b a 
new-style class as well.  Thus type(b()) is b.

As for a check, it really depends on what you mean by "instance-like".  
Are dictionaries "instance-like"?  What about strings?  Integers?

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

Re: Project organization and import

[Dave Baum]

In article <[EMAIL PROTECTED]>,
 "Martin Unsal" <[EMAIL PROTECTED]> wrote:

> That too... although I think that's unfortunate. If reload() were
> reliable, would you use it? Do you think it's inherently unreliable,
> that is, it couldn't be fixed without fundamentally breaking the
> Python language core?

I wrote a module that wraps __import__ and tracks the dependencies of 
imports.  It then allows you to unload any modules whose source have
changed.  That seemed to work out nicely for multi-module projects.

However, one problem I ran into was that dynamic libraries don't get
reloaded, so if you are doing hybrid C++/Python development then this
doesn't help - you still have to restart the whole python process to
pick up changes in your C++ code.

I also didn't do a ton of testing.  It worked for a few small projects
I was working on, but I stopped using it once I ran into the dynamic
library thing, and at this point I'm used to just restarting python
each time.  I'm sure there are some odd things that some python modules
could do that would interfere with the automatic reloading code I
wrote.

If you're interested in the code, drop me an email.

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

Re: read/write to java socket in python

[Dave Baum]

Your server program is using readLine(), which will block until a 
newline is received.  The server code does not write a newline, so it is 
waiting at recv() for data from the server, and the server is still 
waiting for a newline.  If you change the client to do the following, it 
should work:

s.send("Hi Java Server\n");


Dave


In article 
<[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] wrote:

> Hi all,
> 
> I have a problem with reading from a Java server after I have written
> to it - it just hangs. It works fine if I just write to the server and
> not try to write. I have read the HOWTO on sockets - and it states
> that there is a problem (something about flushing), but not what the
> solutions is. Nor do google. Can somebody please help?
> 
> A few lines down you can see the example code that sums up the
> problem. Just change the name of the Python HOST-variable.
> 
> Thanks
> Mads
> 
> 
> This is the client in Python:
> #! /usr/bin/env python
> 
> import sys
> from socket import *
> 
> PORT = 3122
> HOST = 'app-5'
> SUCCESS = 'Success'
> FAILURE = 'Failure'
> 
> s = socket(AF_INET, SOCK_STREAM)
> s.connect((HOST, PORT))
> s.send("Hi Java Server");
> print "Have written, waiting to recieve.."
> print s.recv(1014)
> s.close()
> 
> And this the server in Java:
> import java.io.*;
> import java.net.*;
> 
> public class Server{
> public static void main(String args[]){
> 
> int port = 3122;
> int backLog = 50;
> 
> ServerSocket ss = null;
> try{
> 
> InetAddress localhost =
> InetAddress.getLocalHost();
> ss = new ServerSocket(port, backLog,
> localhost);
> while(true){
> final Socket client = ss.accept();
> new Thread(){
> public void run(){
> try{
> 
> 
> InputStream is =
> client.getInputStream();
> BufferedReader buf =
> new BufferedReader(new InputStreamReader(is));
> print(buf.readLine());
> 
> PrintWriter out = new
> PrintWriter(client.getOutputStream());
> out.write("Hi Python
> Client.");
> out.flush();
> client.close();
> }catch(Exception e)
> {print(e);}
> }
> }.start();
> }
> }catch(Exception e){print(e);}
> }
> 
> private static void print(Object o){System.out.println(o);}
> }
-- 
http://mail.python.org/mailman/listinfo/python-list