Re: How Does requests.get Work?

[Abdur-Rahmaan Janhangeer]

Ah i get it

from .api import request, get, head, post, patch, put, delete, options

Whatever you import in __init__.py, you can access it directly. Thanks!

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy.com  | github

Mauritius


On Thu, Apr 2, 2020 at 10:15 AM Chris Angelico  wrote:

> On Thu, Apr 2, 2020 at 5:12 PM Abdur-Rahmaan Janhangeer
>  wrote:
> >
> > When dev a package, if you can do:
> >
> > >>> from package import x
> >
> > does not mean you can do
> >
> > >>> import package
> > >>> package.x
> >
> > for requests i was wondering how requests package can have
> >
> > >>> requests.get
> >
> > while requests is defined in api.py
> >
>
> Did you have a look at __init__.py?
>
> https://github.com/psf/requests/blob/master/requests/__init__.py
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How Does requests.get Work?

[Chris Angelico]

On Thu, Apr 2, 2020 at 5:12 PM Abdur-Rahmaan Janhangeer
 wrote:
>
> When dev a package, if you can do:
>
> >>> from package import x
>
> does not mean you can do
>
> >>> import package
> >>> package.x
>
> for requests i was wondering how requests package can have
>
> >>> requests.get
>
> while requests is defined in api.py
>

Did you have a look at __init__.py?

https://github.com/psf/requests/blob/master/requests/__init__.py

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How Does requests.get Work?

[Abdur-Rahmaan Janhangeer]

When dev a package, if you can do:

>>> from package import x

does not mean you can do

>>> import package
>>> package.x

for requests i was wondering how requests package can have

>>> requests.get

while requests is defined in api.py

Kind Regards,


Abdur-Rahmaan Janhangeer

https://www.compileralchemy.com
https://www.github.com/Abdur-RahmaanJ

Mauritius

sent from gmail client on Android, that's why the signature is so ugly.

On Thu, 2 Apr 2020, 01:33 Juergen Brendel,  wrote:

>
> Hello!
>
> Can you elaborate on what you mean by "use directly"?
>
> Juergen
>
>
> On Thu, 2020-04-02 at 01:12 +0400, Abdur-Rahmaan Janhangeer wrote:
> > Greetings list,
> >
> > I was viewing requests https://github.com/psf/requests
> >
> > I know we can do `requests.get`
> >
> > Found `get` defined in api.py
> >
> > I would appreciate an explanation as to how to configure the package
> > so
> > that we can use get directly. Thanks.
> >
> > Kind Regards,
> >
> > Abdur-Rahmaan Janhangeer
> > compileralchemy.com  | github
> > 
> > Mauritius
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How Does requests.get Work?

[Juergen Brendel]

Hello!

Can you elaborate on what you mean by "use directly"?

Juergen


On Thu, 2020-04-02 at 01:12 +0400, Abdur-Rahmaan Janhangeer wrote:
> Greetings list,
> 
> I was viewing requests https://github.com/psf/requests
> 
> I know we can do `requests.get`
> 
> Found `get` defined in api.py
> 
> I would appreciate an explanation as to how to configure the package
> so
> that we can use get directly. Thanks.
> 
> Kind Regards,
> 
> Abdur-Rahmaan Janhangeer
> compileralchemy.com  | github
> 
> Mauritius

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

How Does requests.get Work?

[Abdur-Rahmaan Janhangeer]

Greetings list,

I was viewing requests https://github.com/psf/requests

I know we can do `requests.get`

Found `get` defined in api.py

I would appreciate an explanation as to how to configure the package so
that we can use get directly. Thanks.

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy.com  | github

Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exec "x = 3; print x" in a - How does it work?

[Chris Angelico]

On Wed, Mar 9, 2016 at 5:25 PM, Veek. M  wrote:
> ah, okay - i'm familiar with the py3 syntax where you do:
> eval('whatever stmt', globals={}, locals={})
> I suppose this: exec " " in NS; syntax is strictly py2?
>
> Many thanks :)

Yeah, that's one of the things that was cleaned up in Py3. Several
pieces of magic syntax were replaced with perfectly ordinary
functions. While there are plenty of people who complain about having
to put parentheses around their print calls, I'm firmly of the opinion
that print(..., file=somefile) is WAY better than the >> syntax that
Py2 used. I can never remember whether it has to go first or has to go
last, and whether it's >> or >>>, etc, etc. It's magic syntax. Py3?
It's a keyword argument. Easy!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exec "x = 3; print x" in a - How does it work?

[Veek. M]

Steven D'Aprano wrote:

> On Wednesday 09 March 2016 16:27, Veek. M wrote:
> 
>> What is the return value of `exec`? Would that object be then used to
>> iterate the sequence in 'a'? I'm reading this:
>> https://www.python.org/download/releases/2.2.3/descrintro/
> 
> 
> exec is a statement, not a function, so it doesn't have a return
> value.
> 
> Are you referring to this line of code?
> 
> exec "x = 3; print x" in a
> 
> 
> That doesn't return a value. The "in a" part tells exec which
> namespace to execute the code in. It doesn't mean "test if the result
> is found inside sequence a".
> 
> py> namespace = {'__builtins__': None}
> py> exec "x = 3" in namespace
> py> namespace
> {'__builtins__': None, 'x': 3}
> 
> 
> If you leave the "in namespace" part out, then exec will use the
> current namespace, and x will become a local variable.
> 
> 
> What happens if you don't put the special __builtins__ key into the
> namespace? Python adds it for you:
> 
> 
> py> mydict = {}
> py> exec "foo = 99.99" in mydict
> py> mydict.keys()
> ['__builtins__', 'foo']
> 
> 
> 
> What's inside __builtins__? Every single built-in function and class:
> 
> py> mydict['__builtins__']
> {'bytearray': , 'IndexError':  'exceptions.IndexError'>, 'all': ,
> 
> ... dozens more entries ...
> 
> 'OverflowError': }
> 
> 
> 
> 
ah, okay - i'm familiar with the py3 syntax where you do:
eval('whatever stmt', globals={}, locals={})
I suppose this: exec " " in NS; syntax is strictly py2?

Many thanks :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exec "x = 3; print x" in a - How does it work?

[Veek. M]

Ben Finney wrote:

> "Veek. M"  writes:
> 
>> What is the return value of `exec`?
> 
> You can refer to the documentation for questions like that.
> 
> 
>> Would that object be then used to iterate the sequence in 'a'?
> 
> The ‘for’ or ‘while’ statements are correct for iteration.
> 
>> I'm reading this:
>> https://www.python.org/download/releases/2.2.3/descrintro/
> 
> Why?
> 
Well, i had a question on MRO and asked on freenode #python and they 
suggested i read that.

My question was:
class A(x, y, z):
 pass

class x(q,w,r)
 pass

I wanted to know how the __mro__ would be generated (c3 linearization)

I had assumed when using super() it would do:
x, q, w, r, y, z, object
basically hit a base class and finish with all it's parents before 
stepping to the next sibling

But then i read somewhere else that it's like this:
x, y, z, q, w, r, object
and of course if q has base-classes then:
x, y, z, q, w, r, e, f, g
which is utterly confusing because you can't tell by looking where e, f, 
g are coming from (q) in this case..

This doc: 
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/
I was getting all cross-eyed reading this:
'The ancestor tree for our new class is: LoggingOD, LoggingDict, 
OrderedDict, dict, object. For our purposes, the important result is 
that OrderedDict was inserted after LoggingDict and before dict! This 
means that the super() call in LoggingDict.__setitem__ now dispatches 
the key/value update to OrderedDict instead of dict.'

I was wondering why they had chosen this notation over the other.

And if you're wondering why that paper - because i was reading Beazley 
super() pg 120 and the whole hard-coding avoided using super() bit.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exec "x = 3; print x" in a - How does it work?

[Steven D'Aprano]

On Wednesday 09 March 2016 16:27, Veek. M wrote:

> What is the return value of `exec`? Would that object be then used to
> iterate the sequence in 'a'? I'm reading this:
> https://www.python.org/download/releases/2.2.3/descrintro/


exec is a statement, not a function, so it doesn't have a return value.

Are you referring to this line of code?

exec "x = 3; print x" in a


That doesn't return a value. The "in a" part tells exec which namespace to 
execute the code in. It doesn't mean "test if the result is found inside 
sequence a".

py> namespace = {'__builtins__': None}
py> exec "x = 3" in namespace
py> namespace
{'__builtins__': None, 'x': 3}


If you leave the "in namespace" part out, then exec will use the current 
namespace, and x will become a local variable.


What happens if you don't put the special __builtins__ key into the 
namespace? Python adds it for you:


py> mydict = {}
py> exec "foo = 99.99" in mydict
py> mydict.keys()
['__builtins__', 'foo']



What's inside __builtins__? Every single built-in function and class:

py> mydict['__builtins__']
{'bytearray': , 'IndexError': , 'all': , 

... dozens more entries ...

'OverflowError': }




-- 
Steve

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

Re: exec "x = 3; print x" in a - How does it work?

[Ben Finney]

"Veek. M"  writes:

> What is the return value of `exec`?

You can refer to the documentation for questions like that.


> Would that object be then used to iterate the sequence in 'a'?

The ‘for’ or ‘while’ statements are correct for iteration.

> I'm reading this:
> https://www.python.org/download/releases/2.2.3/descrintro/

Why?

-- 
 \  “Generally speaking, the errors in religion are dangerous; |
  `\those in philosophy only ridiculous.” —David Hume, _A Treatise |
_o__)   of Human Nature_, 1739 |
Ben Finney

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

exec "x = 3; print x" in a - How does it work?

[Veek. M]

What is the return value of `exec`? Would that object be then used to 
iterate the sequence in 'a'? I'm reading this: 
https://www.python.org/download/releases/2.2.3/descrintro/ 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: function code snippet that has function calls I have never seen before. How does it work.

[Steven D'Aprano]

On Sun, 4 Oct 2015 04:40 am, Ronald Cosentino wrote:

> def funA(x,y,z):
> return (x+y) * z
> def funB(x,y):
> return(x-y)
> print(funA(4,funB(2,3), funB(3,2)))
> 
> the answer is 3. I don't know how it works.


Break it up and consider it a little at a time, starting with the three
values given to funA:

* calculate 4 (too easy, it's already done)

* calculate funB(2, 3)
  => funB(2, 3) returns 2-3, which gives -1

* calculate funB(3,2)
  => funB(3, 2) returns 3-2, which gives 1


Then pass those three values to the funA function:

* calculate funA(4, -1, 1)
  => which returns (4 + -1)*1, which gives 3


and finally pass that value to print:

* print(3)


which prints 3.




-- 
Steven

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

function code snippet that has function calls I have never seen before. How does it work.

[Ronald Cosentino]

def funA(x,y,z):
return (x+y) * z
def funB(x,y):
return(x-y)
print(funA(4,funB(2,3), funB(3,2)))

the answer is 3. I don't know how it works.

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

Re: function code snippet that has function calls I have never seen before. How does it work.

[Joel Goldstick]

On Sat, Oct 3, 2015 at 1:40 PM, Ronald Cosentino 
wrote:

> def funA(x,y,z):
> return (x+y) * z
>
The above takes 3 values and returns a value


> def funB(x,y):
> return(x-y)
>
The above takes 2 values and returns a value


> print(funA(4,funB(2,3), funB(3,2)))
>

you are printing the result of funA, to which you are passing 4, the value
returned by funB(2,3) and the value returned by funB(3,2)

So, print(funA(4, -1, 1))

Which is 4 + -1 * 1

Which is 3 * 1


>
> the answer is 3. I don't know how it works.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Joel Goldstick
http://joelgoldstick.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: function code snippet that has function calls I have never seen before. How does it work.

[Denis McMahon]

On Sat, 03 Oct 2015 10:40:57 -0700, Ronald Cosentino wrote:

> def funA(x,y,z):
> return (x+y) * z
> def funB(x,y):
> return(x-y)
> print(funA(4,funB(2,3), funB(3,2)))
> 
> the answer is 3. I don't know how it works.

def funA(x, y, z):
return (x+y) * z

def funB(x, y):
return (x-y)

# this line
# print(funA(4,funB(2,3), funB(3,2)))
# can be written as the following 4 lines:

a = funB(2, 3) # 2 - 3 -> -1

b = funB(3, 2) # 3 - 2 -> 1

c = funA(4, a, b) # (4 + -1) * 1 -> 3

print(c) # 3

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: function code snippet that has function calls I have never seen before. How does it work.

[Joseph Lee]

Hi Ronald,
Answers inline.

-Original Message-
From: Python-list
[mailto:python-list-bounces+joseph.lee22590=gmail@python.org] On Behalf
Of Ronald Cosentino
Sent: Saturday, October 3, 2015 10:41 AM
To: python-list@python.org
Subject: function code snippet that has function calls I have never seen
before. How does it work.

def funA(x,y,z):
return (x+y) * z
def funB(x,y):
return(x-y)
print(funA(4,funB(2,3), funB(3,2)))

the answer is 3. I don't know how it works.

JL: Okay, let's step through the print routine.

1. Before print does its job, the function result will be gathered.
2. The argument to print is result of funA, which itself takes result of two
calls to FunB.
3. First, results of funB calls will be gathered (subtracting 3 from 2 and 2
from 3, respectively). So it becomes:
print(funA(4, (2-3), (3-2)))
4. Then funA will continue to perform its job, returning the result for
output. Thus the final expression that print will print is:
print((4+-1) * 1)

When looking at a function that takes result of another function, it is
important to look at what the inner callee does (in this case, look at what
funB does first).
Cheers,
Joseph



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

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

Re: function code snippet that has function calls I have never seen before. How does it work.

[Ervin Hegedüs]

hi,

On Sat, Oct 03, 2015 at 10:40:57AM -0700, Ronald Cosentino wrote:
> def funA(x,y,z):
> return (x+y) * z
> def funB(x,y):
> return(x-y)
> print(funA(4,funB(2,3), funB(3,2)))
> 
> the answer is 3. I don't know how it works.

it's simple:

- there is a "composition of functions", generally
  f(g()) (function in argument list of another function)
- first, Python evaulates the arguments first, from left to right 
- in this point, you'll get -1 for 2nd arg, and 1 for 3rd arg
- then your funcA() will be called with these arguents:
  4, -1, 1
- funcA() calculates this:
  (x+y)*z, in this case (4+(-1))*1


which is 3...


a.


-- 
I � UTF-8
-- 
https://mail.python.org/mailman/listinfo/python-list

how does not work nested comment in python?

[vnkumbhani]

example: 
 
print hello # print comment +world= single line comment
print hello '''print comment''' +world   = multiple line comment
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how does not work nested comment in python?

[Vlastimil Brom]

2013/9/4  vnkumbh...@gmail.com:
 example:

 print hello # print comment +world= single line comment
 print hello '''print comment''' +world   = multiple line comment
 --
 https://mail.python.org/mailman/listinfo/python-list

Hi,
python only has single line comments, which apply from a # to the
end of the respective line.
There are some possibilities/workarounds/hacks for commenting out,
i.e. (temporarily) disabling, parts of the code
if False:
indented original code

Sometimes triple-quoted multiline strings are (mis)used this way
original code
in multiple
lines

which actually converts the code to a not accessible multiline string.
However, triple quoting is not an official means for multiline comments.
What you are seeing in your second example is implicit string
concatenation (which works regardless of the type of the quotes) -
adjacent string literals in the code are joined automatically:
 abc 'def' ghi '''jkl'''
'abcdefghijkl'


hth,
  vbr
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how does not work nested comment in python?

[Dave Angel]

On 4/9/2013 02:13, vnkumbh...@gmail.com wrote:

 example: 
  
 print hello # print comment +world= single line comment

 print hello # print comment +world= single line comment
hello


 print hello '''print comment''' +world   = multiple line comment

 print hello '''print comment''' +world   = multiple line comment
  File stdin, line 1
print hello '''print comment''' +world   = multiple line comment
 ^
SyntaxError: invalid syntax
 print hello '''print comment''' +world
helloprint commentworld

What is your question?  The first line has a comment on it, the second
one does not.

-- 
DaveA


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

Re: how does the % work?

[Tim Roberts]

leonardo tampucciol...@libero.it wrote:

thank you all!

So, what was the problem?
-- 
Tim Roberts, t...@probo.com
Providenza  Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how does the % work?

[Rick Johnson]

On Friday, March 22, 2013 11:29:48 PM UTC-5, Tim Roberts wrote:

 You are using Python 3.  In Python 3, print is a function that returns
 None.  So, the error is exactly correct.  

Wait a second... if he is in-fact using Python 3, then why did the call to a 
non-existent function named raw_input not throw an error first? Not to 
mention THREE calls to a non-existent function named raw_input! Hmm, my guess 
is that the python interpreter was too busy gossiping about that overblown 
sexual harassment BS at PyCon to even notice. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how does the % work?

[Steven D'Aprano]

On Fri, 22 Mar 2013 21:29:48 -0700, Tim Roberts wrote:

 leonardo selmi l.se...@icloud.com wrote:

i wrote this example :

name = raw_input(What is your name?) 
quest = raw_input(What is your quest?) 
color = raw_input(What is your favorite color?)

print Ah, so your name is %s, your quest is %s, and your favorite
color is %s.  % (name, quest, color)
 
 No, you didn't.  You wrote:
 
 print('''Ah, so your name is %s, your quest is %s, and your
 favorite color is %s.''') % (name, quest, color)


The difference between those two statements may not be entirely clear to 
someone not experienced in reading code carefully.

Consider the difference between:

  print(a % b)

  print(a) % b

In the first example, the round brackets group the a % b, which is 
calculated first, then printed.

In the second example, in Python 3, the print(a) is called first, which 
returns None, and then None % b is calculated, which raises an 
exception.

Just to add confusion, the two lines are exactly the same in Python 2, 
where Print is not a function! 


 You are using Python 3.  In Python 3, print is a function that returns
 None.  So, the error is exactly correct.  To fix it, you need to have
 the % operator operate on the string, not on the result of the print
 function:
 
 print('''Ah, so your name is %s, your quest is %s, and your
 favorite color is %s.''' % (name, quest, color))

Exactly correct.



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

Re: how does the % work?

[Rick Johnson]

On Saturday, March 23, 2013 2:38:23 AM UTC-5, Steven D'Aprano wrote:
 On Fri, 22 Mar 2013 21:29:48 -0700, Tim Roberts wrote:

  print('''Ah, so your name is %s, your quest is %s, and your
  favorite color is %s.''') % (name, quest, color)
 
 The difference between those two statements may not be entirely clear to 
 someone not experienced in reading code carefully.

I think the main problem with the code the OP presented is his attempt to stuff 
a long string literal into the print function. He should have separated the 
format string from the format operation:

py fmtstr = '''Ah, so your name is %s, your quest is %s, and your
favorite color is %s.'''
py print(fmtstr%(1,2,3))
Ah, so your name is 1, your quest is 2, and your
favorite color is 3.

Sorry but i was too lazy to type out three string literal arguments, and 
instead, I reached for the low hanging syntactical sweetness of the integer 
peach. Mmm peaches!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how does the % work?

[Michael Torrie]

On 03/23/2013 01:38 AM, Steven D'Aprano wrote:
 Just to add confusion, the two lines are exactly the same in Python 2, 
 where Print is not a function! 

Perhaps this is a good reason use the slightly more complicated but
easier to get right format method.

print ({0}, {1}, {2}.format(1,2,3))

And it's worth noting that using the string formatter or the old %
operator on a string works anywhere where there're strings, not just in
the print function.

b = The answer was %d % answer

or

b = The answer was {0}.format(answer)

On the topic of print, I can see the logic in print being a function
now, but I have always preferred it as a print statement; it just looked
cleaner.  That was one of the things that initially attracted me to
python.  But the reality is print isn't used for much in real programs
other than console debug messages.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how does the % work?

[leonardo]

thank you all!


Il 23/03/2013 8.38, Steven D'Aprano ha scritto:

On Fri, 22 Mar 2013 21:29:48 -0700, Tim Roberts wrote:


leonardo selmi l.se...@icloud.com wrote:

i wrote this example :

name = raw_input(What is your name?)
quest = raw_input(What is your quest?)
color = raw_input(What is your favorite color?)

print Ah, so your name is %s, your quest is %s, and your favorite
color is %s.  % (name, quest, color)

No, you didn't.  You wrote:

print('''Ah, so your name is %s, your quest is %s, and your
 favorite color is %s.''') % (name, quest, color)


The difference between those two statements may not be entirely clear to
someone not experienced in reading code carefully.

Consider the difference between:

   print(a % b)

   print(a) % b

In the first example, the round brackets group the a % b, which is
calculated first, then printed.

In the second example, in Python 3, the print(a) is called first, which
returns None, and then None % b is calculated, which raises an
exception.

Just to add confusion, the two lines are exactly the same in Python 2,
where Print is not a function!



You are using Python 3.  In Python 3, print is a function that returns
None.  So, the error is exactly correct.  To fix it, you need to have
the % operator operate on the string, not on the result of the print
function:

print('''Ah, so your name is %s, your quest is %s, and your
 favorite color is %s.''' % (name, quest, color))

Exactly correct.





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

Re: how does the % work?

[Steven D'Aprano]

On Sat, 23 Mar 2013 09:57:48 -0600, Michael Torrie wrote:

 On 03/23/2013 01:38 AM, Steven D'Aprano wrote:
 Just to add confusion, the two lines are exactly the same in Python 2,
 where Print is not a function!
 
 Perhaps this is a good reason use the slightly more complicated but
 easier to get right format method.
 
 print ({0}, {1}, {2}.format(1,2,3))


Misplaced parentheses are possible either way.

print ({0}, {1}, {2}.format(1,2,3))
print ({0}, {1}, {2}).format(1,2,3)


 And it's worth noting that using the string formatter or the old %
 operator on a string works anywhere where there're strings, not just in
 the print function.


Very true.



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

how does the % work?

[leonardo selmi]

hi guys

i wrote this example :

name = raw_input(What is your name?)
quest = raw_input(What is your quest?)
color = raw_input(What is your favorite color?)

print Ah, so your name is %s, your quest is %s, 
and your favorite color is %s.  % (name, quest, color)

but i get this error:  Traceback (most recent call last):
  File /Users/leonardo/print.py, line 5, in module
favourite color is %s.''') % (name, quest, color)
TypeError: unsupported operand type(s) for %: 'NoneType' and 'tuple'

how can i solve it?

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

Re: how does the % work?

[John Gordon]

In mailman.3612.1363971987.2939.python-l...@python.org leonardo selmi 
l.se...@icloud.com writes:

 hi guys

 i wrote this example :

 name = raw_input(What is your name?)
 quest = raw_input(What is your quest?)
 color = raw_input(What is your favorite color?)

 print Ah, so your name is %s, your quest is %s, 
 and your favorite color is %s.  % (name, quest, color)

 but i get this error:  Traceback (most recent call last):
   File /Users/leonardo/print.py, line 5, in module
 favourite color is %s.''') % (name, quest, color)
 TypeError: unsupported operand type(s) for %: 'NoneType' and 'tuple'

 how can i solve it?

Are you sure you've given us the exact code?  The printed text doesn't
exactly match.  (favorite vs. favourite, three double-quotes vs
three single-quotes, etc.)

The error message also says that the print statement has a
close-parenthesis after the string and before the arguments, which may be
real problem.

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, The Gashlycrumb Tinies

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

Re: [Python-Help] how does the % work?

[bob gailer]

It is better to post to just one list at a time.

On 3/22/2013 1:06 PM, leonardo selmi wrote:

name = raw_input(What is your name?)
quest = raw_input(What is your quest?)
color = raw_input(What is your favorite color?)

print Ah, so your name is %s, your quest is %s,
and your favorite color is %s.  % (name, quest, color)

Runs OK for me!

The traceback does not match the code. Please post the code that 
actually generated this:


  File /Users/leonardo/print.py, line 5, in module
favourite color is %s.''') % (name, quest, color)
TypeError: unsupported operand type(s) for %: 'NoneType' and 'tuple'


--
Bob Gailer
919-636-4239
Chapel Hill NC

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

Re: how does the % work?

[Rick Johnson]

On Friday, March 22, 2013 12:06:18 PM UTC-5, leonardo selmi wrote:
 hi guys
 
 i wrote this example :
 
 name = raw_input(What is your name?)
 quest = raw_input(What is your quest?)
 color = raw_input(What is your favorite color?)
 
 print Ah, so your name is %s, your quest is %s, 
 and your favorite color is %s.  % (name, quest, color)
 
 but i get this error:  Traceback (most recent call last):
   File /Users/leonardo/print.py, line 5, in module 
 favourite color is %s.''') % (name, quest, color)
 TypeError: unsupported operand type(s) for %: 'NoneType'
 and 'tuple'
 
 how can i solve it?

I would advise as your first course of action to invoke your own problem 
solving skills. Let's break your code down into two distinct parts. 

1. ask the user three questions
2. pass the three responses into a string formatting operation.

Anytime you have inputs that are breaking some functionality (and I'm not sure 
if these inputs ARE breaking anything), then you need to *test* those inputs 
before just *blindly* passing them off to other code. This means you need to do 
two tests. 

1. Find out what possible responses could be a result of raw_input. This is 
difficult, because the user could enter anything, even NOTHING. Remember: 
Fools are too cleaver!. Normally user input requires some sort of validation. 
If you just echoing the input, probably not, but in the real world you will 
need to verify that you are not dealing with a loony.

2. Inject some known values into the string format operation to insure your 
syntax and expectations are correct.

But most importantly, run the code and observe the Exception message. The 
exception was a gift from the creators of Python, just as pain is a gift from 
your creator. 

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

Re: how does the % work?

[Tim Roberts]

leonardo selmi l.se...@icloud.com wrote:

i wrote this example :

name = raw_input(What is your name?)
quest = raw_input(What is your quest?)
color = raw_input(What is your favorite color?)

print Ah, so your name is %s, your quest is %s, 
and your favorite color is %s.  % (name, quest, color)

No, you didn't.  You wrote:

print('''Ah, so your name is %s, your quest is %s, and your
favorite color is %s.''') % (name, quest, color)

but i get this error:  Traceback (most recent call last):
  File /Users/leonardo/print.py, line 5, in module
favourite color is %s.''') % (name, quest, color)
TypeError: unsupported operand type(s) for %: 'NoneType' and 'tuple'

how can i solve it?

You are using Python 3.  In Python 3, print is a function that returns
None.  So, the error is exactly correct.  To fix it, you need to have the %
operator operate on the string, not on the result of the print function:

print('''Ah, so your name is %s, your quest is %s, and your
favorite color is %s.''' % (name, quest, color))
-- 
Tim Roberts, t...@probo.com
Providenza  Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How does .rjust() work and why it places characters relative to previous one, not to first character - placed most to left - or to left side of screen?

[Peter Otten]

crispy wrote:

 Thanks, i've finally came to solution.
 
 Here it is - http://codepad.org/Q70eGkO8
 
 def pairwiseScore(seqA, seqB):
 
 score = 0
 bars = [str(' ') for x in seqA] # ...
 length = len(seqA)
 similarity = []
 
 for x in xrange(length):
 
 if seqA[x] == seqB[x]: # ...
 if (x = 1) and (seqA[x - 1] == seqB[x - 1]): # ...
 score += 3
 similarity.append(x)
 else:
 score += 1
 similarity.append(x)
 else:
 score -= 1
 
 for x in similarity:
 bars[x] = '|' # ... 
 
 return ''.join((seqA, '\n', ''.join(bars), '\n', seqB, '\n', 'Score: 
', str(score)))
 

Python has a function zip() that lets you iterate over multiple sequences 
simultaneously. Instead of

for i in xrange(len(a)):
x = a[i]
y = b[i]
...

you can write

for x, y in zip(a, b):
...

Also, you can build the bar list immediately and avoid the similarity list.

With these changes:

def pairwise_score(a, b):
score = 0
was_equal = False
bars = []
for x, y in zip(a, b):
equal = x == y
if equal:
bars.append(|)
if was_equal:
score += 3
else:
score += 1
else:
bars.append( )
score -= 1
was_equal = equal
print a
print .join(bars)
print b
print Score:, score

If you want to take this even further you can use a score matrix instead of 
if ... else:

def pairwise_score(a, b):
score = 0
was_equal = False
bars = []
matrix = [[-1, 1], [-1, 3]]
for x, y in zip(a, b):
equal = x == y
score += matrix[was_equal][equal]
bars.append( |[equal])
was_equal = equal
print a
print .join(bars)
print b
print Score:, score

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

How does .rjust() work and why it places characters relative to previous one, not to first character - placed most to left - or to left side of screen?

[crispy]

I have an example:

def pairwiseScore(seqA, seqB):

prev = -1
score = 0
length = len(seqA)
similarity = []
relative_similarity = []

for x in xrange(length):

if seqA[x] == seqB[x]:
if (x = 1) and (seqA[x - 1] == seqB[x - 1]):
score += 3
similarity.append(x)
else:
score += 1
similarity.append(x)
else:
score -= 1

for x in similarity:

relative_similarity.append(x - prev)
prev = x

return ''.join((seqA, '\n', ''.join(['|'.rjust(x) for x in 
relative_similarity]), '\n', seqB, '\n', 'Score: ', str(score)))


print pairwiseScore(ATTCGT, ATCTAT), '\n', '\n', 
pairwiseScore(GATAAATCTGGTCT, CATTCATCATGCAA), '\n', '\n', 
pairwiseScore('AGCG', 'ATCG'), '\n', '\n', pairwiseScore('ATCG', 'ATCG')

which returns:

ATTCGT
||   |
ATCTAT
Score: 2 

GATAAATCTGGTCT
 ||  |||  |
CATTCATCATGCAA
Score: 4 

AGCG
| ||
ATCG
Score: 4 

ATCG

ATCG
Score: 10


But i created this with some help from one person. Earlier, this code was 
devoided of these few lines:


prev = -1
relative_similarity = []


for x in similarity:

relative_similarity.append(x - prev)
prev = x

The method looked liek this:

def pairwiseScore(seqA, seqB):

score = 0
length = len(seqA)
similarity = []

for x in xrange(length):

if seqA[x] == seqB[x]:
if (x = 1) and (seqA[x - 1] == seqB[x - 1]):
score += 3
similarity.append(x)
else:
score += 1
similarity.append(x)
else:
score -= 1

return ''.join((seqA, '\n', ''.join(['|'.rjust(x) for x in 
similarity]), '\n', seqB, '\n', 'Score: ', str(score)))

and produced this output:

ATTCGT
|||
ATCTAT
Score: 2 

GATAAATCTGGTCT
| || |  | |
CATTCATCATGCAA
Score: 4 

AGCG
| |  |
ATCG
Score: 4 

ATCG
|| |  |
ATCG
Score: 10

So I have guessed, that characters processed by .rjust() function, are placed 
in output, relative to previous ones - NOT to first, most to left placed, 
character.
Why it works like that? What builtn-in function can format output, to make 
every character be placed as i need - relative to the first character, placed 
most to left side of screen.

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

Re: How does .rjust() work and why it places characters relative to previous one, not to first character - placed most to left - or to left side of screen?

[crispy]

Here's first code - http://codepad.org/RcKTTiYa

And here's second - http://codepad.org/zwEQKKeV
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How does .rjust() work and why it places characters relative to previous one, not to first character - placed most to left - or to left side of screen?

[Dave Angel]

On 08/19/2012 12:25 PM, crispy wrote:
 SNIP
 So I have guessed, that characters processed by .rjust() function, are placed 
 in output, relative to previous ones - NOT to first, most to left placed, 
 character.

rjust() does not print to the console, it just produces a string.  So if
you want to know how it works, you need to either read about it, or
experiment with it.

Try   help(.rjust) to see a simple description of it.  (If you're
not familiar with the interactive interpreter's help() function, you owe
it to yourself to learn it).

Playing with it:

print abcd.rjust(8, -)   producesabcd

for i in range(5): print a.rjust(i, -)
produces:

a
a
-a
--a
---a

In each case, the number of characters produced is no larger than i.  No
consideration is made to other strings outside of the literal passed
into the method.


 Why it works like that? 

In your code, you have the rjust() method inside a loop, inside a join,
inside a print.  it makes a nice, impressive single line, but clearly
you don't completely understand what the pieces are, nor how they work
together.  Since the join is combining (concatenating) strings that are
each being produced by rjust(), it's the join() that's making this look
relative to you.


 What builtn-in function can format output, to make every character be placed 
 as i need - relative to the first character, placed most to left side of 
 screen.

If you want to randomly place characters on the screen, you either want
a curses-like package, or a gui.  i suspect that's not at all what you want.

if you want to randomly change characters in a pre-existing string,
which will then be printed to the console, then I could suggest an
approach (untested)

res = [ ] * length
for column in similarity:
res[column] = |
res = .join(res)



-- 

DaveA

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

Re: How does .rjust() work and why it places characters relative to previous one, not to first character - placed most to left - or to left side of screen?

[crispy]

W dniu niedziela, 19 sierpnia 2012 19:31:30 UTC+2 użytkownik Dave Angel napisał:
 On 08/19/2012 12:25 PM, crispy wrote:
 
  SNIP
 
  So I have guessed, that characters processed by .rjust() function, are 
  placed in output, relative to previous ones - NOT to first, most to left 
  placed, character.
 
 
 
 rjust() does not print to the console, it just produces a string.  So if
 
 you want to know how it works, you need to either read about it, or
 
 experiment with it.
 
 
 
 Try   help(.rjust) to see a simple description of it.  (If you're
 
 not familiar with the interactive interpreter's help() function, you owe
 
 it to yourself to learn it).
 
 
 
 Playing with it:
 
 
 
 print abcd.rjust(8, -)   producesabcd
 
 
 
 for i in range(5): print a.rjust(i, -)
 
 produces:
 
 
 
 a
 
 a
 
 -a
 
 --a
 
 ---a
 
 
 
 In each case, the number of characters produced is no larger than i.  No
 
 consideration is made to other strings outside of the literal passed
 
 into the method.
 
 
 
 
 
  Why it works like that? 
 
 
 
 In your code, you have the rjust() method inside a loop, inside a join,
 
 inside a print.  it makes a nice, impressive single line, but clearly
 
 you don't completely understand what the pieces are, nor how they work
 
 together.  Since the join is combining (concatenating) strings that are
 
 each being produced by rjust(), it's the join() that's making this look
 
 relative to you.
 
 
 
 
 
  What builtn-in function can format output, to make every character be 
  placed as i need - relative to the first character, placed most to left 
  side of screen.
 
 
 
 If you want to randomly place characters on the screen, you either want
 
 a curses-like package, or a gui.  i suspect that's not at all what you want.
 
 
 
 if you want to randomly change characters in a pre-existing string,
 
 which will then be printed to the console, then I could suggest an
 
 approach (untested)
 
 
 
 res = [ ] * length
 
 for column in similarity:
 
 res[column] = |
 
 res = .join(res)
 
 
 
 
 
 
 
 -- 
 
 
 
 DaveA

Thanks, i've finally came to solution.

Here it is - http://codepad.org/Q70eGkO8

def pairwiseScore(seqA, seqB):

score = 0
bars = [str(' ') for x in seqA] #create a list filled with number of spaces 
equal to length of seqA string. It could be also seqB, because both are meant 
to have same length
length = len(seqA)
similarity = []

for x in xrange(length):

if seqA[x] == seqB[x]: #check if for every index 'x', corresponding 
character is same in both seqA and seqB strings
if (x = 1) and (seqA[x - 1] == seqB[x - 1]): #if 'x' is greater 
than or equal to 1 and characters under the previous index, were same in both 
seqA and seqB strings, do..
score += 3
similarity.append(x)
else:
score += 1
similarity.append(x)
else:
score -= 1

for x in similarity:
bars[x] = '|' #for every index 'x' in 'bars' list, replace space with 
'|' (pipe/vertical bar) character 

return ''.join((seqA, '\n', ''.join(bars), '\n', seqB, '\n', 'Score: ', 
str(score)))

print pairwiseScore(ATTCGT, ATCTAT), '\n', '\n', 
pairwiseScore(GATAAATCTGGTCT, CATTCATCATGCAA), '\n', '\n', 
pairwiseScore('AGCG', 'ATCG'), '\n', '\n', pairwiseScore('ATCG', 'ATCG')
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How does this work?

[Jon Clements]

On Jun 5, 4:37 am, Ben Finney ben+pyt...@benfinney.id.au wrote:
 jyoun...@kc.rr.com writes:
  I was surfing around looking for a way to split a list into equal
  sections. I came upon this algorithm:

   f = lambda x, n, acc=[]: f(x[n:], n, acc+[(x[:n])]) if x else acc
   f(Hallo Welt, 3)
  ['Hal', 'lo ', 'Wel', 't']

  (http://stackoverflow.com/questions/312443/how-do-you-split-a-list-int...)

 This is an excellent example of why “clever” code is to be shunned.
 Whoever wrote this needs to spend more time trying to get their code
 past a peer review; the above would be rejected until it was re-written
 to be clear.

 Here is my attempt to write the above to be clear (and fixing a couple
 of bugs too):

     def split_slices(seq, slicesize, accumulator=None):
          Return a list of slices from `seq` each of size `slicesize`.

             :param seq: The sequence to split.
             :param slicesize: The maximum size of each slice.
             :param accumulator: A sequence of existing slices to which
                 ours should be appended.
             :return: A list of the slices. Each item will be a slice
                 from the original `seq` of `slicesize` length; the last
                 item may be shorter if there were fewer than `slicesize`
                 items remaining.

             
         if accumulator is None:
             accumulator = []
         if seq:
             slice = seq[:slicesize]
             result = split_slices(
                 seq[slicesize:], slicesize, accumulator + [slice])
         else:
             result = accumulator
         return result

  It doesn't work with a huge list, but looks like it could be handy in
  certain circumstances. I'm trying to understand this code, but am
  totally lost. I know a little bit about lambda, as well as the ternary
  operator

 In Python, ‘lambda’ is merely an alternative syntax for creating
 function objects. The resulting object *is* a function, so I've written
 the above using the ‘def’ syntax for clarity.

 The ternary operator is often useful for very simple expressions, but
 quickly becomes too costly to read when the expression is complex. The
 above is one where the writer is so much in love with the ternary
 operator that they have crammed far too much complexity into a single
 expression.

  Just curious if anyone could explain how this works or maybe share a link
  to a website that might explain this?

 Does the above help?

 --
  \       “We must find our way to a time when faith, without evidence, |
   `\    disgraces anyone who would claim it.” —Sam Harris, _The End of |
 _o__)                                                     Faith_, 2004 |
 Ben Finney

Just my 2p, but isn't the itertools grouper recipe prudent?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How does this work?

[Ben Finney]

Jon Clements jon...@googlemail.com writes:

 On Jun 5, 4:37 am, Ben Finney ben+pyt...@benfinney.id.au wrote:
  jyoun...@kc.rr.com writes:
   (http://stackoverflow.com/questions/312443/how-do-you-split-a-list-int...)
 
  This is an excellent example of why “clever” code is to be shunned.
  Whoever wrote this needs to spend more time trying to get their code
  past a peer review; the above would be rejected until it was
  re-written to be clear.
 
  Here is my attempt to write the above to be clear (and fixing a couple
  of bugs too):

 Just my 2p, but isn't the itertools grouper recipe prudent?

Oh, if we go looking for ways to improve what that code is doing, there
are many things wrong with it, not least that it is re-implementing code
that already exists in the standard library.

But I'll leave that to the several superior answers at the Stackoverflow
question.

-- 
 \   “Pray, v. To ask that the laws of the universe be annulled in |
  `\ behalf of a single petitioner confessedly unworthy.” —Ambrose |
_o__)   Bierce, _The Devil's Dictionary_, 1906 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

How does this work?

[jyoung79]

I was surfing around looking for a way to split a list into equal sections.  I 
came 
upon this algorithm:

 f = lambda x, n, acc=[]: f(x[n:], n, acc+[(x[:n])]) if x else acc
 f(Hallo Welt, 3)
['Hal', 'lo ', 'Wel', 't']

(http://stackoverflow.com/questions/312443/how-do-you-split-a-list-into-evenly-sized-chunks-in-python/312644)

It doesn't work with a huge list, but looks like it could be handy in certain 
circumstances.  I'm trying to understand this code, but am totally lost.  I 
know a little bit about lambda, as well as the ternary operator, but how 
does this part work:

 f('dude'[3:], 3, []+[('dude'[:3])])
['dud', 'e']

Is that some sort of function call, or something else?  I'm guessing it works 
recursively?

Just curious if anyone could explain how this works or maybe share a link 
to a website that might explain this?

Thanks.

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

Re: How does this work?

[Ben Finney]

jyoun...@kc.rr.com writes:

 I was surfing around looking for a way to split a list into equal
 sections. I came upon this algorithm:

  f = lambda x, n, acc=[]: f(x[n:], n, acc+[(x[:n])]) if x else acc
  f(Hallo Welt, 3)
 ['Hal', 'lo ', 'Wel', 't']

 (http://stackoverflow.com/questions/312443/how-do-you-split-a-list-into-evenly-sized-chunks-in-python/312644)

This is an excellent example of why “clever” code is to be shunned.
Whoever wrote this needs to spend more time trying to get their code
past a peer review; the above would be rejected until it was re-written
to be clear.

Here is my attempt to write the above to be clear (and fixing a couple
of bugs too):

def split_slices(seq, slicesize, accumulator=None):
 Return a list of slices from `seq` each of size `slicesize`.

:param seq: The sequence to split.
:param slicesize: The maximum size of each slice.
:param accumulator: A sequence of existing slices to which
ours should be appended.
:return: A list of the slices. Each item will be a slice
from the original `seq` of `slicesize` length; the last
item may be shorter if there were fewer than `slicesize`
items remaining.


if accumulator is None:
accumulator = []
if seq:
slice = seq[:slicesize]
result = split_slices(
seq[slicesize:], slicesize, accumulator + [slice])
else:
result = accumulator
return result

 It doesn't work with a huge list, but looks like it could be handy in
 certain circumstances. I'm trying to understand this code, but am
 totally lost. I know a little bit about lambda, as well as the ternary
 operator

In Python, ‘lambda’ is merely an alternative syntax for creating
function objects. The resulting object *is* a function, so I've written
the above using the ‘def’ syntax for clarity.

The ternary operator is often useful for very simple expressions, but
quickly becomes too costly to read when the expression is complex. The
above is one where the writer is so much in love with the ternary
operator that they have crammed far too much complexity into a single
expression.

 Just curious if anyone could explain how this works or maybe share a link 
 to a website that might explain this?

Does the above help?

-- 
 \   “We must find our way to a time when faith, without evidence, |
  `\disgraces anyone who would claim it.” —Sam Harris, _The End of |
_o__) Faith_, 2004 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Grant Edwards]

On 2008-02-27, Micah Cowan [EMAIL PROTECTED] wrote:
 Grant Edwards wrote:
 On 2008-02-26, Micah Cowan [EMAIL PROTECTED] wrote:
 
 7stud, what you seem to be missing, and what I'm not sure if anyone has
 clarified for you (I have only skimmed the thread), is that in TCP,
 connections are uniquely identified by a /pair/ of sockets (where
 socket here means an address/port tuple, not a file descriptor).
 
 Using the word socket as a name for an address/port tuple is
 precisely what's causing all the confusion.  An address/port
 tuple is simply not a socket from a python/Unix/C point of
 view, and a socket is not an address/port tuple.

 FWIW, the word was used to mean the address/port tuple (RFC
 793) before there was ever a python/Unix/C concept of
 socket.

I could claim I was innocently unaware of that usage, though I
have read the RFCs, so I'll go with Steve Martin's classic
excuse: I forgot.

 And I totally agree that it's confusing; but I submit that
 IETF has a stronger claim over the term than Unix/C/Python,
 which could have just stuck with network descriptor or some
 such. ;)

They probably had to come up with a system call name that was
uniquely identified by six characters or something like that.

-- 
Grant Edwards   grante Yow! Does someone from
  at   PEORIA have a SHORTER
   visi.comATTENTION span than me?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[7stud]

On Feb 25, 10:00 pm, Roy Smith [EMAIL PROTECTED] wrote:
 In article
 [EMAIL PROTECTED],

  7stud [EMAIL PROTECTED] wrote:
  But your claim that the server doesn't change its port flies in the
  face of every description I've read about TCP connections and
  accept().  The articles and books I've read all claim that the server
  port 5053 is a 'listening' port only.  Thereafter, when a client sends
  a request for a connection to the listening port, the accept() call on
  the server creates a new socket for communication between the client
  and server, and then the server goes back to listening on the original
  socket.

 You're confusing port and socket.

 A port is an external thing.  It exists in the minds and hearts of packets
 on the network, and in the RFCs which define the TCP protocol (UDP too, but
 let's keep this simple).

 A socket is an internal thing.  It is a programming abstraction.  Sockets
 can exist that aren't bound to ports, and several different sockets can be
 bound to the same port.  Just like there can be multiple file descriptors
 which are connected to a given file on disk.

 The TCP protocol defines a state machine which determines what packets
 should be sent in response when certain kinds of packets get received.  The
 protocol doesn't say how this state machine should be implemented (or even
 demands that it be implemented at all).  It only requires that a TCP host
 behave in a way which the state machine defines.

 In reality, whatever operating system you're running on almost certainly
 implements in the kernel a state machine as described by TCP.  That state
 machine has two sides.  On the outside is the network interface, which
 receives and transmits packets.  On the inside is the socket interface to
 user-mode applications.  The socket is just the API by which a user program
 interacts with the kernel to get it to do the desired things on the network
 interface(s).

 Now, what the articles and books say is that there is a listening SOCKET.  
 And when you accept a connection on that socket (i.e. a TCP three-way
 handshake is consummated on the network), the way the socket API deals with
 that is to generate a NEW socket (via the accept system call).  There
 really isn't any physical object that either socket represents.  They're
 both just programming abstractions.

 Does that help?

If two sockets are bound to the same host and port on the server, how
does data sent by the client get routed?  Can both sockets recv() the
data?

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

Re: network programming: how does s.accept() work?

[7stud]

On Feb 25, 10:08 pm, Steve Holden [EMAIL PROTECTED] wrote:
 There can be many TCP connections to a server all using the same
 endpoint. Take a look at the traffic coming out of any busy web server:
 everything that comes out of the same server comes from port 80. That
 doesn't stop it listening for more connections on port 80.


---
When you surf the Web, say to http://www.google.com, your Web browser
is a client. The program you contact at Google is a server. When a
server is run, it sets up business at a certain port, say 80 in the
Web case. It then waits for clients to contact it. When a client does
so, the server will usually assign a new port, say 56399, specifically
for communication with that client, and then resume watching port 80
for new requests.
---
http://heather.cs.ucdavis.edu/~matloff/Python/PyNet.pdf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Hrvoje Niksic]

7stud [EMAIL PROTECTED] writes:

 When you surf the Web, say to http://www.google.com, your Web browser
 is a client. The program you contact at Google is a server. When a
 server is run, it sets up business at a certain port, say 80 in the
 Web case. It then waits for clients to contact it. When a client does
 so, the server will usually assign a new port, say 56399, specifically
 for communication with that client, and then resume watching port 80
 for new requests.

Actually the client is the one that allocates a new port.  All
connections to a server remain on the same port, the one it listens
on:

 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 s.bind(('127.0.0.1', 1))
 s.listen(1)
 s.accept()
# now, connect to port 1 from elsewhere
(socket._socketobject object at 0xb7adf6f4, ('127.0.0.1', 36345))
 s1 = _[0]
 s1
socket._socketobject object at 0xb7adf6f4
 s1.getsockname()
('127.0.0.1', 1)# note the same port, not a different one
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Frank Millman]

7stud wrote:

 If two sockets are bound to the same host and port on the server, how
 does data sent by the client get routed?  Can both sockets recv() the
 data?

I have learned a lot of stuff I did not know before from this thread,
so I think I can answer that.

There must be a layer of software that listens at the port. When it
receives a packet, it can tell which client sent the packet (host and
port number). It uses that to look up which socket is handling that
particular connection, and passes it as input to that socket.

Therefore each socket only receives its own input, and is not aware of
anything received for any other connection.

Not a technical explanation, but I think it describes what happens.

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

Re: network programming: how does s.accept() work?

[Steve Holden]

7stud wrote:
 On Feb 25, 10:00 pm, Roy Smith [EMAIL PROTECTED] wrote:
 In article
 [EMAIL PROTECTED],

  7stud [EMAIL PROTECTED] wrote:
 But your claim that the server doesn't change its port flies in the
 face of every description I've read about TCP connections and
 accept().  The articles and books I've read all claim that the server
 port 5053 is a 'listening' port only.  Thereafter, when a client sends
 a request for a connection to the listening port, the accept() call on
 the server creates a new socket for communication between the client
 and server, and then the server goes back to listening on the original
 socket.
 You're confusing port and socket.

 A port is an external thing.  It exists in the minds and hearts of packets
 on the network, and in the RFCs which define the TCP protocol (UDP too, but
 let's keep this simple).

 A socket is an internal thing.  It is a programming abstraction.  Sockets
 can exist that aren't bound to ports, and several different sockets can be
 bound to the same port.  Just like there can be multiple file descriptors
 which are connected to a given file on disk.

 The TCP protocol defines a state machine which determines what packets
 should be sent in response when certain kinds of packets get received.  The
 protocol doesn't say how this state machine should be implemented (or even
 demands that it be implemented at all).  It only requires that a TCP host
 behave in a way which the state machine defines.

 In reality, whatever operating system you're running on almost certainly
 implements in the kernel a state machine as described by TCP.  That state
 machine has two sides.  On the outside is the network interface, which
 receives and transmits packets.  On the inside is the socket interface to
 user-mode applications.  The socket is just the API by which a user program
 interacts with the kernel to get it to do the desired things on the network
 interface(s).

 Now, what the articles and books say is that there is a listening SOCKET.  
 And when you accept a connection on that socket (i.e. a TCP three-way
 handshake is consummated on the network), the way the socket API deals with
 that is to generate a NEW socket (via the accept system call).  There
 really isn't any physical object that either socket represents.  They're
 both just programming abstractions.

 Does that help?
 
 If two sockets are bound to the same host and port on the server, how
 does data sent by the client get routed?  Can both sockets recv() the
 data?
 
Routing traditionally means passing hop-by-hop from one IP address to 
another, but I'll assume that you are actually concerned about delivery 
of packets from two separate clients - lets call them (addr1, p1) and 
(addrs, p2) - to two server processes both using the same endpoint 
address which we will call (addrS, pS). In all cases the first memebr of 
the tuple is an IP address and the second is a port number.

Note that the condition I mentioned earlier (with the caveat added by 
Roy) ensures that while addr1 and addr2 might be the same, or p1 and p2 
might be the same, they can *never* be the same together: if the TCP 
layer at addr1 allocates port p1 to one client process, when another 
client process asks for an ephemeral port TCP guarantees that it wonn't 
be given p1, because that is already logged as in use by another process.

So, in Python terms that represents a guarantee that

 (addr1, p1) != (addr2, p2)

and consequently (addr1, p1, addrS, pS) != (addr2, p2, addrS, pS)

Now, when a packet arrives at the server system addressed to the server 
endpoint, the TCP layer (whcih maintains a record of *both* endpoints 
for each connection) simply looks at the incoming address and port 
number to determine which process, of the potentially many using (addrS, 
pS), it needs to be delivered to.

If this isn't enough then you should really take this problem to a 
TCP/IP group. It's pretty basic, and until you understand it you will 
never make sense of TCP/IP client/server communications.

   http://holdenweb.com/linuxworld/NetProg.pdf

might help, but I don't guarantee it.

regards
  Steve

-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: network programming: how does s.accept() work?

[Micah Cowan]

Hrvoje Niksic wrote:
 7stud [EMAIL PROTECTED] writes:
 
 When you surf the Web, say to http://www.google.com, your Web browser
 is a client. The program you contact at Google is a server. When a
 server is run, it sets up business at a certain port, say 80 in the
 Web case. It then waits for clients to contact it. When a client does
 so, the server will usually assign a new port, say 56399, specifically
 for communication with that client, and then resume watching port 80
 for new requests.
 
 Actually the client is the one that allocates a new port.  All
 connections to a server remain on the same port, the one it listens
 on:

(Hey, I know you! ;) )

Right.

7stud, what you seem to be missing, and what I'm not sure if anyone has
clarified for you (I have only skimmed the thread), is that in TCP,
connections are uniquely identified by a /pair/ of sockets (where
socket here means an address/port tuple, not a file descriptor). It is
fine for many, many connections, using the same local port and IP
address, so long as the other end has either a different IP address _or_
a different port. There is no issue with lots of processes sharing the
same socket for various separate connections, because the /pair/ of
sockets is what identifies them. See the Multiplexing portion of
section 1.5 of the TCP spec (http://www.ietf.org/rfc/rfc0793.txt).

Reading some of what you've written elsewhere on this thread, you seem
to be confusing this address/port stuff with what accept() returns. This
is hardly surprising, as unfortunately, both things are called
sockets: the former is called a socket in the various RFCs, the latter
is called a socket in documentation for the Berkeley sockets and similar
APIs. What accept() returns is a new file descriptor, but the local
address-and-port associated with this new thing is still the very same
ones that were used for listen(). All the incoming packets are still
directed at port 80 (say) of the local server by the remote client.

It's probably worth mentioning at this point, that while what I said
about many different processes all using the same local address/port
combination is true, in implementations of the standard Berkeley sockets
API the only way you'd _arrive_ at that situation is that all of those
different connections that have the same local address/port combination
is that they all came from the same listen() call (ignoring mild
exceptions that involve one server finishing up connections while
another accepts new ones). Because while one process has a socket
descriptor bound to a particular address/port, no other process is
allowed to bind to that combination. However, for listening sockets,
that one process is allowed to accept many connections on the same
address/port. It can handle all those connections itself, or it can fork
new processes, or it can pass these connected sockets down to
already-forked processes. But all of them continue to be bound to the
same local address-and-port.

Note that, if the server's port were to change arbitrarily for every
successful call to accept(), it would make it much more difficult to
filter and/or analyze TCP traffic. If you're running, say, tcpdump, the
knowledge that all the packets on a connection that was originally
directed at port 80 of google.com, will continue to go to port 80 at
google.com (even though there are many, many, many other connections out
there on the web from other machines that are all also directed at port
80 of google.com), is crucial to knowing which packets to watch for
while you're looking at the traffic.

-- 
HTH,
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Grant Edwards]

On 2008-02-26, Micah Cowan [EMAIL PROTECTED] wrote:

 7stud, what you seem to be missing, and what I'm not sure if anyone has
 clarified for you (I have only skimmed the thread), is that in TCP,
 connections are uniquely identified by a /pair/ of sockets (where
 socket here means an address/port tuple, not a file descriptor).

Using the word socket as a name for an address/port tuple is
precisely what's causing all the confusion.  An address/port
tuple is simply not a socket from a python/Unix/C point of
view, and a socket is not an address/port tuple.

 It is fine for many, many connections, using the same local
 port and IP address, so long as the other end has either a
 different IP address _or_ a different port. There is no issue
 with lots of processes sharing the same socket for various
 separate connections, because the /pair/ of sockets is what
 identifies them. See the Multiplexing portion of section 1.5
 of the TCP spec (http://www.ietf.org/rfc/rfc0793.txt).

Exactly.

 Reading some of what you've written elsewhere on this thread,
 you seem to be confusing this address/port stuff with what
 accept() returns. This is hardly surprising, as unfortunately,
 both things are called sockets: the former is called a
 socket in the various RFCs,

I must admit wasn't familiar with that usage (or had forgotten
it).

-- 
Grant Edwards   grante Yow! Look DEEP into the
  at   OPENINGS!!  Do you see any
   visi.comELVES or EDSELS ... or a
   HIGHBALL?? ...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Roy Smith]

In article 
[EMAIL PROTECTED],
 7stud [EMAIL PROTECTED] wrote:

 If two sockets are bound to the same host and port on the server, how
 does data sent by the client get routed?  Can both sockets recv() the
 data?

Undefined.

You certainly won't find the answer in the RFCs which define the protocol 
because sockets aren't part of the protocol.

Unfortunately, you won't find the answer in the Socket API documentation 
either because the socket API documentation is pretty vague about most 
stuff.

One possible answer is that the operating system won't let you bind two 
sockets to the same (address, port) pair.  But, another possibility is that 
it will.  And even if it won't, consider the case of a process which forks; 
the child inherits the already bound socket from the parent.

So, either way, you're left with the question, what happens with two 
sockets both bound to the same (address, port) pair?  For the sake of 
simplicity, I'm assuming UDP, so there's no connection 4-tuple to worry 
about.  The answer is, again, undefined.  One reasonable answer is that 
packets received by the operating system are doled out round-robin to all 
the sockets bound to that port.  Another is that they're duplicated and 
delivered to all sockets.  Anything is possible.

But, as other posters have said, this really isn't a Python question.  This 
is a networking API question.  Python just gives you a very thin layer on 
top of whatever the operating system gives you, and lets all the details of 
the OS implementation quirks shine through.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Gabriel Genellina]

En Tue, 26 Feb 2008 07:53:24 -0200, 7stud [EMAIL PROTECTED]  
escribió:

 ---
 When you surf the Web, say to http://www.google.com, your Web browser
 is a client. The program you contact at Google is a server. When a
 server is run, it sets up business at a certain port, say 80 in the
 Web case. It then waits for clients to contact it. When a client does
 so, the server will usually assign a new port, say 56399, specifically
 for communication with that client, and then resume watching port 80
 for new requests.
 ---
 http://heather.cs.ucdavis.edu/~matloff/Python/PyNet.pdf

You should *not* trust all you find on the Net...

-- 
Gabriel Genellina

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

Re: network programming: how does s.accept() work?

[Micah Cowan]

Grant Edwards wrote:
 On 2008-02-26, Micah Cowan [EMAIL PROTECTED] wrote:
 
 7stud, what you seem to be missing, and what I'm not sure if anyone has
 clarified for you (I have only skimmed the thread), is that in TCP,
 connections are uniquely identified by a /pair/ of sockets (where
 socket here means an address/port tuple, not a file descriptor).
 
 Using the word socket as a name for an address/port tuple is
 precisely what's causing all the confusion.  An address/port
 tuple is simply not a socket from a python/Unix/C point of
 view, and a socket is not an address/port tuple.

FWIW, the word was used to mean the address/port tuple (RFC 793) before
there was ever a python/Unix/C concept of socket.

And I totally agree that it's confusing; but I submit that IETF has a
stronger claim over the term than Unix/C/Python, which could have just
stuck with network descriptor or some such. ;)

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Micah Cowan]

Gabriel Genellina wrote:
 En Tue, 26 Feb 2008 07:53:24 -0200, 7stud [EMAIL PROTECTED]
 escribió:
 
 ---
 When you surf the Web, say to http://www.google.com, your Web browser
 is a client. The program you contact at Google is a server. When a
 server is run, it sets up business at a certain port, say 80 in the
 Web case. It then waits for clients to contact it. When a client does
 so, the server will usually assign a new port, say 56399, specifically
 for communication with that client, and then resume watching port 80
 for new requests.
 ---
 http://heather.cs.ucdavis.edu/~matloff/Python/PyNet.pdf
 
 You should *not* trust all you find on the Net...

Didn't give it a thorough read, but I did see a section about the server
setting up a new socket, called a connection socket.

Which isn't incorrect, but proves Grant's point rather well, that the
confusion is due to the overloaded term socket. In that context, it's
speaking quite clearly of the Python/C/Unix concept of a socket, and
not (as some other texts do) of the address/port combination.

To reiterate for 7stud, accepting a new connection socket does _not_
change the address or port from the originally bound for-listening socket.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
-- 
http://mail.python.org/mailman/listinfo/python-list

network programming: how does s.accept() work?

[7stud]

I have the following two identical clients

#test1.py:---
import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

host = 'localhost'
port = 5052  #server port

s.connect((host, port))
print s.getsockname()

response = []
while 1:
piece = s.recv(1024)
if piece == '':
break

response.append(piece)


#test3.py:
import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

host = 'localhost'
port = 5052  #server port

s.connect((host, port))
print s.getsockname()

response = []
while 1:
piece = s.recv(1024)
if piece == '':
break

response.append(piece)


and this basic server:

#test2.py:--
import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

host = ''
port = 5052

s.bind((host, port))
s.listen(5)


while 1:
newsock, client_addr = s.accept()
print orignal socket:, s.getsockname()

print new socket:, newsock.getsockname()
print new socket:, newsock.getpeername()
print


I started the server, and then I started the clients one by one.  I
expected both clients to hang since they don't get notified that the
server is done sending data, and I expected the server output to show
that accept() created two new sockets.  But this is the output I got
from the server:

original socket: ('0.0.0.0', 5052)
new socket, self: ('127.0.0.1', 5052)
new socket, peer: ('127.0.0.1', 50816)

original socket: ('0.0.0.0', 5052)
new socket, self: ('127.0.0.1', 5052)
new socket, peer: ('127.0.0.1', 50818)

The first client I started generated this output:

('127.0.0.1', 50816)

And when I ran the second client, the first client disconnected, and
the second client produced this output:

('127.0.0.1', 50818)

and then the second client hung.  I expected the server output to be
something like this:

original socket: ('127.0.0.1', 5052)
new socket, self: ('127.0.0.1', 5053)
new socket, peer: ('127.0.0.1', 50816)

original socket: ('0.0.0.0', 5052)
new socket, self: ('127.0.0.1', 5054)
new socket, peer: ('127.0.0.1', 50818)

And I expected both clients to hang.  Can someone explain how accept()
works?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[bockman]

On 25 Feb, 09:51, 7stud [EMAIL PROTECTED] wrote:
 I have the following two identical clients

 #test1.py:---
 import socket

 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

 host = 'localhost'
 port = 5052  #server port

 s.connect((host, port))
 print s.getsockname()

 response = []
 while 1:
     piece = s.recv(1024)
     if piece == '':
         break

     response.append(piece)

 #test3.py:
 import socket

 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

 host = 'localhost'
 port = 5052  #server port

 s.connect((host, port))
 print s.getsockname()

 response = []
 while 1:
     piece = s.recv(1024)
     if piece == '':
         break

     response.append(piece)

 and this basic server:

 #test2.py:--
 import socket

 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

 host = ''
 port = 5052

 s.bind((host, port))
 s.listen(5)

 while 1:
     newsock, client_addr = s.accept()
     print orignal socket:, s.getsockname()

     print new socket:, newsock.getsockname()
     print new socket:, newsock.getpeername()
     print

 I started the server, and then I started the clients one by one.  I
 expected both clients to hang since they don't get notified that the
 server is done sending data, and I expected the server output to show
 that accept() created two new sockets.  But this is the output I got
 from the server:

 original socket: ('0.0.0.0', 5052)
 new socket, self: ('127.0.0.1', 5052)
 new socket, peer: ('127.0.0.1', 50816)

 original socket: ('0.0.0.0', 5052)
 new socket, self: ('127.0.0.1', 5052)
 new socket, peer: ('127.0.0.1', 50818)

 The first client I started generated this output:

 ('127.0.0.1', 50816)

 And when I ran the second client, the first client disconnected, and
 the second client produced this output:

 ('127.0.0.1', 50818)

 and then the second client hung.  I expected the server output to be
 something like this:

 original socket: ('127.0.0.1', 5052)
 new socket, self: ('127.0.0.1', 5053)
 new socket, peer: ('127.0.0.1', 50816)

 original socket: ('0.0.0.0', 5052)
 new socket, self: ('127.0.0.1', 5054)
 new socket, peer: ('127.0.0.1', 50818)

 And I expected both clients to hang.  Can someone explain how accept()
 works?

I guess (but I did not try it) that the problem is not accept(), that
should work as you expect,
but the fact that at the second connection your code actually throws
away the first connection
by reusing the same variables without storing the previous values.
This could make the Python
garbage collector to attempt freeing the socket object created with
the first connection, therefore
closing the connection.

If I'm right, your program should work as you expect if you for
instance collect in a list the sockets
returned by accept.

Ciao

FB


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

Re: network programming: how does s.accept() work?

[7stud]

On Feb 25, 2:43 am, [EMAIL PROTECTED] wrote:
 On 25 Feb, 09:51, 7stud [EMAIL PROTECTED] wrote:



  I have the following two identical clients

  #test1.py:---
  import socket

  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

  host = 'localhost'
  port = 5052  #server port

  s.connect((host, port))
  print s.getsockname()

  response = []
  while 1:
      piece = s.recv(1024)
      if piece == '':
          break

      response.append(piece)

  #test3.py:
  import socket

  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

  host = 'localhost'
  port = 5052  #server port

  s.connect((host, port))
  print s.getsockname()

  response = []
  while 1:
      piece = s.recv(1024)
      if piece == '':
          break

      response.append(piece)

  and this basic server:

  #test2.py:--
  import socket

  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

  host = ''
  port = 5052

  s.bind((host, port))
  s.listen(5)

  while 1:
      newsock, client_addr = s.accept()
      print orignal socket:, s.getsockname()

      print new socket:, newsock.getsockname()
      print new socket:, newsock.getpeername()
      print

  I started the server, and then I started the clients one by one.  I
  expected both clients to hang since they don't get notified that the
  server is done sending data, and I expected the server output to show
  that accept() created two new sockets.  But this is the output I got
  from the server:

  original socket: ('0.0.0.0', 5052)
  new socket, self: ('127.0.0.1', 5052)
  new socket, peer: ('127.0.0.1', 50816)

  original socket: ('0.0.0.0', 5052)
  new socket, self: ('127.0.0.1', 5052)
  new socket, peer: ('127.0.0.1', 50818)

  The first client I started generated this output:

  ('127.0.0.1', 50816)

  And when I ran the second client, the first client disconnected, and
  the second client produced this output:

  ('127.0.0.1', 50818)

  and then the second client hung.  I expected the server output to be
  something like this:

  original socket: ('127.0.0.1', 5052)
  new socket, self: ('127.0.0.1', 5053)
  new socket, peer: ('127.0.0.1', 50816)

  original socket: ('0.0.0.0', 5052)
  new socket, self: ('127.0.0.1', 5054)
  new socket, peer: ('127.0.0.1', 50818)

  And I expected both clients to hang.  Can someone explain how accept()
  works?

 I guess (but I did not try it) that the problem is not accept(), that
 should work as you expect,
 but the fact that at the second connection your code actually throws
 away the first connection
 by reusing the same variables without storing the previous values.
 This could make the Python
 garbage collector to attempt freeing the socket object created with
 the first connection, therefore
 closing the connection.

 If I'm right, your program should work as you expect if you for
 instance collect in a list the sockets
 returned by accept.

 Ciao
 
 FB

The question I'm really trying to answer is: if a client connects to a
host at a specific port, but the server changes the port when it
creates a new socket with accept(), how does data sent by the client
arrive at the correct port?  Won't the client be sending data to the
original port e.g. port 5052 in the client code above?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[7stud]

On Feb 25, 2:43 am, [EMAIL PROTECTED] wrote:

 by reusing the same variables without storing the previous values.
 This could make the Python
 garbage collector to attempt freeing the socket object created with
 the first connection, therefore
 closing the connection.

 If I'm right, your program should work as you expect if you for
 instance collect in a list the sockets
 returned by accept.


Yes, you are right about that.  This code prevents the first client
from disconnecting:

newsocks = []
client_addys = []

while 1:
newsock, client_addr = s.accept()
newsocks.append(newsock)
client_addys.append(client_addr)

print original socket:, s.getsockname()

print new socket, self:, newsock.getsockname()
print new socket, peer:, newsock.getpeername()
print
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[7stud]

On Feb 25, 4:08 am, 7stud [EMAIL PROTECTED] wrote:

 The question I'm really trying to answer is: if a client connects to a
 host at a specific port, but the server changes the port when it
 creates a new socket with accept(), how does data sent by the client
 arrive at the correct port?  Won't the client be sending data to the
 original port e.g. port 5052 in the client code above?


If I change the clients to this:


import socket
import time
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

host = 'localhost'
port = 5052  #server port

print s.getsockname()  #NEW LINE
s.connect((host, port))
print s.getsockname()

response = []
while 1:
piece = s.recv(1024)
if piece == '':
break

response.append(piece)


Then I get output from the clients like this:

('0.0.0.0', 0)
('127.0.0.1', 51439)

('0.0.0.0', 0)
('127.0.0.1', 51440)


The server port 5052(i.e. the one used in connect()) is not listed
there. That output indicates that the client socket is initially
created with some place holder values, i.e. 0.0.0.0, 0.  Then accept()
apparently sends a message back to the client that in effect says,
Hey, in the future send me data on port 51439.  Then the client
fills in that port along with the ip address in its socket object.
Thereafter, any data sent using that socket is sent to that port and
that ip address.





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

Re: network programming: how does s.accept() work?

[bockman]

 The question I'm really trying to answer is: if a client connects to a
 host at a specific port, but the server changes the port when it
 creates a new socket with accept(), how does data sent by the client
 arrive at the correct port?  Won't the client be sending data to the
 original port e.g. port 5052 in the client code above?


I'm not an expert, never used TCP/IP below the socket abstraction
level, but I imagine
that after accept, the client side of the connection is someow
'rewired' with the new
socket created on the server side.

Anyhow, this is not python-related, since the socket C library behaves
exactly in the same way.

Ciao
-
FB

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

Re: network programming: how does s.accept() work?

[7stud]

On Feb 25, 5:17 am, 7stud [EMAIL PROTECTED] wrote:
 On Feb 25, 4:08 am, 7stud [EMAIL PROTECTED] wrote:



  The question I'm really trying to answer is: if a client connects to a
  host at a specific port, but the server changes the port when it
  creates a new socket with accept(), how does data sent by the client
  arrive at the correct port?  Won't the client be sending data to the
  original port e.g. port 5052 in the client code above?

 If I change the clients to this:

 import socket
 import time
 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

 host = 'localhost'
 port = 5052  #server port

 print s.getsockname()  #NEW LINE
 s.connect((host, port))
 print s.getsockname()

 response = []
 while 1:
     piece = s.recv(1024)
     if piece == '':
         break

     response.append(piece)

 Then I get output from the clients like this:

 ('0.0.0.0', 0)
 ('127.0.0.1', 51439)

 ('0.0.0.0', 0)
 ('127.0.0.1', 51440)

 The server port 5052(i.e. the one used in connect()) is not listed
 there. That output indicates that the client socket is initially
 created with some place holder values, i.e. 0.0.0.0, 0.  Then accept()
 apparently sends a message back to the client that in effect says,
 Hey, in the future send me data on port 51439.  Then the client
 fills in that port along with the ip address in its socket object.
 Thereafter, any data sent using that socket is sent to that port and
 that ip address.

Implicit in that description is that the client must get assigned a
port number before the call to connect(), or maybe the call to
connect() assigns a port number to the client.  In any case, the
server has to receive both the client's ip address and port number as
part of the client's request for a connection in order for the server
to know where to send the response.  The server then uses that ip
address and port number to send back a message to the client that
tells the client what port number future communications need to be
sent to.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Thomas Bellman]

7stud [EMAIL PROTECTED] wrote:

 The question I'm really trying to answer is: if a client connects to a
 host at a specific port, but the server changes the port when it
 creates a new socket with accept(), how does data sent by the client
 arrive at the correct port?  Won't the client be sending data to the
 original port e.g. port 5052 in the client code above?

The answer is that the server *doesn't* change its port.  As you
could see in the output of your server, the socket that accept()
returned also had local port 5052.  Each *client* will however
get a unique local port at *its* end.

A TCP connection is identified by a four-tuple:

( localaddr, localport, remoteaddr, remoteport )

Note that what is local and what is remote is relative to which
process you are looking from.  If the four-tuple for a specific
TCP connection is ( 127.0.0.1, 5052, 127.0.0.1, 50816 ) in your
server, it will be ( 127.0.0.1, 50816, 127.0.0.1, 5052 ) in the
client for the very same TCP connection.

Since your client hasn't bound its socket to a specific port, the
kernel will chose a local port for you when you do a connect().
The chosen port will be more or less random, but it will make
sure that the four-tuple identifying the TCP connection will be
unique.


-- 
Thomas Bellman,   Lysator Computer Club,   Linköping University,  Sweden
There are many causes worth dying for, but  !  bellman @ lysator.liu.se
 none worth killing for. -- Gandhi  !  Make Love -- Nicht Wahr!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[7stud]

On Feb 25, 10:56 am, Thomas Bellman [EMAIL PROTECTED] wrote:
 7stud [EMAIL PROTECTED] wrote:
  The question I'm really trying to answer is: if a client connects to a
  host at a specific port, but the server changes the port when it
  creates a new socket with accept(), how does data sent by the client
  arrive at the correct port?  Won't the client be sending data to the
  original port e.g. port 5052 in the client code above?

 The answer is that the server *doesn't* change its port.  As you
 could see in the output of your server, the socket that accept()
 returned also had local port 5052.  Each *client* will however
 get a unique local port at *its* end.

 A TCP connection is identified by a four-tuple:

     ( localaddr, localport, remoteaddr, remoteport )

 Note that what is local and what is remote is relative to which
 process you are looking from.  If the four-tuple for a specific
 TCP connection is ( 127.0.0.1, 5052, 127.0.0.1, 50816 ) in your
 server, it will be ( 127.0.0.1, 50816, 127.0.0.1, 5052 ) in the
 client for the very same TCP connection.

 Since your client hasn't bound its socket to a specific port, the
 kernel will chose a local port for you when you do a connect().
 The chosen port will be more or less random, but it will make
 sure that the four-tuple identifying the TCP connection will be
 unique.


You seem to be describing what I see:

server output-
original socket: ('0.0.0.0', 5053)
new socket, self: ('127.0.0.1', 5053)
new socket, peer: ('127.0.0.1', 49302)

original socket: ('0.0.0.0', 5053)
new socket, self: ('127.0.0.1', 5053)
new socket, peer: ('127.0.0.1', 49303)

---client1 output-
('0.0.0.0', 0)
('127.0.0.1', 49302)

---client2 output-
('0.0.0.0', 0)
('127.0.0.1', 49303)


But your claim that the server doesn't change its port flies in the
face of every description I've read about TCP connections and
accept().  The articles and books I've read all claim that the server
port 5053 is a 'listening' port only.  Thereafter, when a client sends
a request for a connection to the listening port, the accept() call on
the server creates a new socket for communication between the client
and server, and then the server goes back to listening on the original
socket.  Here are two sources for that claim:

Socket Programming How To:
http://www.amk.ca/python/howto/sockets/

Tutorial on Network Programming with Python:
http://heather.cs.ucdavis.edu/~matloff/Python/PyNet.pdf

In either case, there are still some things about the output that
don't make sense to me.  Why does the server initially report that its
ip address is 0.0.0.0:

original socket: ('0.0.0.0', 5053)

I would expect the reported ip address to be '127.0.0.1'.  Also, since
a socket is uniquely identified by an ip address and port number, then
the ('0.0.0.0', 5053) socket is not the same as this socket:

new socket, self: ('127.0.0.1', 5053)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Grant Edwards]

On 2008-02-25, 7stud [EMAIL PROTECTED] wrote:
 On Feb 25, 10:56 am, Thomas Bellman [EMAIL PROTECTED] wrote:
 7stud [EMAIL PROTECTED] wrote:
  The question I'm really trying to answer is: if a client connects to a
  host at a specific port, but the server changes the port when it
  creates a new socket with accept(), how does data sent by the client
  arrive at the correct port?  Won't the client be sending data to the
  original port e.g. port 5052 in the client code above?

 The answer is that the server *doesn't* change its port.  As you
 could see in the output of your server, the socket that accept()
 returned also had local port 5052.  Each *client* will however
 get a unique local port at *its* end.

 A TCP connection is identified by a four-tuple:

     ( localaddr, localport, remoteaddr, remoteport )

 Note that what is local and what is remote is relative to which
 process you are looking from.  If the four-tuple for a specific
 TCP connection is ( 127.0.0.1, 5052, 127.0.0.1, 50816 ) in your
 server, it will be ( 127.0.0.1, 50816, 127.0.0.1, 5052 ) in the
 client for the very same TCP connection.

 Since your client hasn't bound its socket to a specific port, the
 kernel will chose a local port for you when you do a connect().
 The chosen port will be more or less random, but it will make
 sure that the four-tuple identifying the TCP connection will be
 unique.


 But your claim that the server doesn't change its port flies in the
 face of every description I've read about TCP connections and
 accept().

Then the descriptions are wrong.

 The articles and books I've read all claim that the server
 port 5053 is a 'listening' port only.

Not true.

 Thereafter, when a client sends a request for a connection to
 the listening port, the accept() call on the server creates a
 new socket for communication between the client and server,

True.  But, it doesn't change the local port number.  

Both the listing socket and the connected socket are using
local port number 5053.

 and then the server goes back to listening on the original
 socket.

That's true.

 I would expect the reported ip address to be '127.0.0.1'.
 Also, since a socket is uniquely identified by an ip address
 and port number,

It isn't.

1) You seem to be conflating sockets and TCP connections.  A
   socket is a kernel-space data structure used to provide a
   user-space API to the network stack.  In user-space it's
   identified by an integer index into a per-process table of
   file-like-objects.  That socket may or may not have a TCP
   connection associated with it.  It may or may not be bound
   to an IP address and/or port.  It is not uniquely identified
   by an IP address and port number.

2) A tcp connection is a _different_ thing (though it also
   corresponds to a kernel-space data structure), and as Thomas
   said, it is uniquely identified by the a four-tuple:

     (localaddr, localport, remoteaddr, remoteport)

   [Technically, it's probably a 5-tuple with the above
   elements along with a 'connection type' element, but since
   we're only discussing TCP in this thread, we can ignore the
   connection type axis and only consider the 4-axis space of
   TCP connections.]
 
   When a second client connects to the server on port 5053,
   the first two elements in the tuple will be the same.  One
   or both of the last two elements will be different.
 
 then the ('0.0.0.0', 5053) socket is not the same as this
 socket:

 new socket, self: ('127.0.0.1', 5053)

Referring to sockets using that notation doesn't really make
sense.  There can be more than one socket associated with the
local address ('127.0.0.1', 5053) or to any other ip/port tuple
you'd like to pick.

-- 
Grant Edwards   grante Yow! YOU PICKED KARL
  at   MALDEN'S NOSE!!
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Gabriel Genellina]

En Mon, 25 Feb 2008 20:03:02 -0200, 7stud [EMAIL PROTECTED]  
escribió:
 On Feb 25, 10:56 am, Thomas Bellman [EMAIL PROTECTED] wrote:
 7stud [EMAIL PROTECTED] wrote:

 In either case, there are still some things about the output that
 don't make sense to me.  Why does the server initially report that its
 ip address is 0.0.0.0:

 original socket: ('0.0.0.0', 5053)

Because you called bind with None (or '' ?) as its first argument; that  
means: listen on any available interface

 I would expect the reported ip address to be '127.0.0.1'.  Also, since
 a socket is uniquely identified by an ip address and port number, then
 the ('0.0.0.0', 5053) socket is not the same as this socket:

 new socket, self: ('127.0.0.1', 5053)

You got this *after* a connection was made, coming from your own PC.   
127.0.0.1 is your local IP; the name localhost should resolve to that  
number. If you have a LAN, try running the client on another PC. Or  
connect to Internet and run the netstat command to see the connected  
pairs.

-- 
Gabriel Genellina

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

Re: network programming: how does s.accept() work?

[Roy Smith]

In article 
[EMAIL PROTECTED],
 7stud [EMAIL PROTECTED] wrote:

 But your claim that the server doesn't change its port flies in the
 face of every description I've read about TCP connections and
 accept().  The articles and books I've read all claim that the server
 port 5053 is a 'listening' port only.  Thereafter, when a client sends
 a request for a connection to the listening port, the accept() call on
 the server creates a new socket for communication between the client
 and server, and then the server goes back to listening on the original
 socket.

You're confusing port and socket.

A port is an external thing.  It exists in the minds and hearts of packets 
on the network, and in the RFCs which define the TCP protocol (UDP too, but 
let's keep this simple).

A socket is an internal thing.  It is a programming abstraction.  Sockets 
can exist that aren't bound to ports, and several different sockets can be 
bound to the same port.  Just like there can be multiple file descriptors 
which are connected to a given file on disk.

The TCP protocol defines a state machine which determines what packets 
should be sent in response when certain kinds of packets get received.  The 
protocol doesn't say how this state machine should be implemented (or even 
demands that it be implemented at all).  It only requires that a TCP host 
behave in a way which the state machine defines.

In reality, whatever operating system you're running on almost certainly 
implements in the kernel a state machine as described by TCP.  That state 
machine has two sides.  On the outside is the network interface, which 
receives and transmits packets.  On the inside is the socket interface to 
user-mode applications.  The socket is just the API by which a user program 
interacts with the kernel to get it to do the desired things on the network 
interface(s).

Now, what the articles and books say is that there is a listening SOCKET.  
And when you accept a connection on that socket (i.e. a TCP three-way 
handshake is consummated on the network), the way the socket API deals with 
that is to generate a NEW socket (via the accept system call).  There 
really isn't any physical object that either socket represents.  They're 
both just programming abstractions.

Does that help?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Roy Smith]

In article [EMAIL PROTECTED],
 Gabriel Genellina [EMAIL PROTECTED] wrote:

 En Mon, 25 Feb 2008 20:03:02 -0200, 7stud [EMAIL PROTECTED]  
 escribió:
  On Feb 25, 10:56 am, Thomas Bellman [EMAIL PROTECTED] wrote:
  7stud [EMAIL PROTECTED] wrote:
 
  In either case, there are still some things about the output that
  don't make sense to me.  Why does the server initially report that its
  ip address is 0.0.0.0:
 
  original socket: ('0.0.0.0', 5053)
 
 Because you called bind with None (or '' ?) as its first argument; that  
 means: listen on any available interface

It really means, Listen on ALL available interfaces.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Steve Holden]

7stud wrote:
 On Feb 25, 10:56 am, Thomas Bellman [EMAIL PROTECTED] wrote:
 7stud [EMAIL PROTECTED] wrote:
 The question I'm really trying to answer is: if a client connects to a
 host at a specific port, but the server changes the port when it
 creates a new socket with accept(), how does data sent by the client
 arrive at the correct port?  Won't the client be sending data to the
 original port e.g. port 5052 in the client code above?
 The answer is that the server *doesn't* change its port.  As you
 could see in the output of your server, the socket that accept()
 returned also had local port 5052.  Each *client* will however
 get a unique local port at *its* end.

 A TCP connection is identified by a four-tuple:

 ( localaddr, localport, remoteaddr, remoteport )

 Note that what is local and what is remote is relative to which
 process you are looking from.  If the four-tuple for a specific
 TCP connection is ( 127.0.0.1, 5052, 127.0.0.1, 50816 ) in your
 server, it will be ( 127.0.0.1, 50816, 127.0.0.1, 5052 ) in the
 client for the very same TCP connection.

 Since your client hasn't bound its socket to a specific port, the
 kernel will chose a local port for you when you do a connect().
 The chosen port will be more or less random, but it will make
 sure that the four-tuple identifying the TCP connection will be
 unique.

 
 You seem to be describing what I see:
 
 server output-
 original socket: ('0.0.0.0', 5053)
 new socket, self: ('127.0.0.1', 5053)
 new socket, peer: ('127.0.0.1', 49302)
 
 original socket: ('0.0.0.0', 5053)
 new socket, self: ('127.0.0.1', 5053)
 new socket, peer: ('127.0.0.1', 49303)
 
 ---client1 output-
 ('0.0.0.0', 0)
 ('127.0.0.1', 49302)
 
 ---client2 output-
 ('0.0.0.0', 0)
 ('127.0.0.1', 49303)
 
 
 But your claim that the server doesn't change its port flies in the
 face of every description I've read about TCP connections and
 accept().  The articles and books I've read all claim that the server
 port 5053 is a 'listening' port only.  Thereafter, when a client sends
 a request for a connection to the listening port, the accept() call on
 the server creates a new socket for communication between the client
 and server, and then the server goes back to listening on the original
 socket.  Here are two sources for that claim:
 
There can be many TCP connections to a server all using the same 
endpoint. Take a look at the traffic coming out of any busy web server: 
everything that comes out of the same server comes from port 80. That 
doesn't stop it listening for more connections on port 80.

The server disambiguates the packets when it demultiplexes the 
connection packet streams by using the remote endpoint to differentiate 
between packets that are part of different connections. TCP guarantees 
that no two ephemeral port connections from the same client will use the 
same port.

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: network programming: how does s.accept() work?

[Roy Smith]

In article [EMAIL PROTECTED],
 Steve Holden [EMAIL PROTECTED] wrote:

  TCP guarantees 
 that no two ephemeral port connections from the same client will use the 
 same port.

Where client is defined as IP Address.  You could certainly have a 
remote machine that has multiple IP addresses using the same remote port 
number on different IP addresses for simultaneous connections to the same 
local port.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: network programming: how does s.accept() work?

[Steve Holden]

Roy Smith wrote:
 In article [EMAIL PROTECTED],
  Steve Holden [EMAIL PROTECTED] wrote:
 
  TCP guarantees 
 that no two ephemeral port connections from the same client will use the 
 same port.
 
 Where client is defined as IP Address.  You could certainly have a 
 remote machine that has multiple IP addresses using the same remote port 
 number on different IP addresses for simultaneous connections to the same 
 local port.

Correct.
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

How does unicode() work?

[Robert Latest]

Here's a test snippet...

import sys
for k in sys.stdin:
print '%s - %s' % (k, k.decode('iso-8859-1'))

...but it barfs when actually fed with iso8859-1 characters. How is this 
done right?

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

Re: How does unicode() work?

[Fredrik Lundh]

Robert Latest wrote:

 Here's a test snippet...
 
 import sys
 for k in sys.stdin:
 print '%s - %s' % (k, k.decode('iso-8859-1'))
 
 ...but it barfs when actually fed with iso8859-1 characters. How is this 
 done right?

it's '%s - %s' % (byte string, unicode string) that barfs.  try doing

import sys
for k in sys.stdin:
 print '%s - %s' % (repr(k), k.decode('iso-8859-1'))

instead, to see what's going on.

/F

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

Re: How does unicode() work?

[Robert Latest]

Robert Latest wrote:
 ...but it barfs when actually fed with iso8859-1 characters.

Specifically, it says:

UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 0: 
ordinal not in range(128)

which doesn't make sense to me, because I specifically asked for the 
iso8859-1 decoder, not the 'ascii' one.

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

Re: How does unicode() work?

[Fredrik Lundh]

Carsten Haese wrote:

 If that really is the line that barfs, wouldn't it make more sense to
 repr() the unicode object in the second position?
 
 import sys
 for k in sys.stdin:
  print '%s - %s' % (k, repr(k.decode('iso-8859-1')))
 
 Also, I'm not sure if the OP has told us the truth about his code and/or
 his error message. The implicit str() call done by formatting a unicode
 object with %s would raise a UnicodeEncodeError, not the
 UnicodeDecodeError that the OP is reporting. So either I need more
 coffee or there is something else going on here that hasn't come to
 light yet.

When mixing Unicode with byte strings, Python attempts to decode the 
byte string, not encode the Unicode string.

In this case, Python first inserts the non-ASCII byte string in %s - 
%s and gets a byte string.  It then attempts to insert the non-ASCII 
Unicode string, and realizes that it has to convert the (partially 
built) target string to Unicode for that to work.  Which results in a 
*UnicodeDecodeError*.

  %s - %s % (åäö, åäö)
'\x86\x84\x94 - \x86\x84\x94'

  %s - %s % (uåäö, uåäö)
u'\xe5\xe4\xf6 - \xe5\xe4\xf6'

  %s - %s % (åäö, uåäö)
Traceback (most recent call last):
   File stdin, line 1, in module
UnicodeDecodeError: 'ascii' codec can't decode byte 0x86 ...

(the actual implementation differs a bit from the description above, but 
the behaviour is identical).

/F

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

Re: How does unicode() work?

[Carsten Haese]

On Wed, 2008-01-09 at 13:44 +0100, Fredrik Lundh wrote:
 Robert Latest wrote:
 
  Here's a test snippet...
  
  import sys
  for k in sys.stdin:
  print '%s - %s' % (k, k.decode('iso-8859-1'))
  
  ...but it barfs when actually fed with iso8859-1 characters. How is this 
  done right?
 
 it's '%s - %s' % (byte string, unicode string) that barfs.  try doing
 
 import sys
 for k in sys.stdin:
  print '%s - %s' % (repr(k), k.decode('iso-8859-1'))
 
 instead, to see what's going on.

If that really is the line that barfs, wouldn't it make more sense to
repr() the unicode object in the second position?

import sys
for k in sys.stdin:
 print '%s - %s' % (k, repr(k.decode('iso-8859-1')))

Also, I'm not sure if the OP has told us the truth about his code and/or
his error message. The implicit str() call done by formatting a unicode
object with %s would raise a UnicodeEncodeError, not the
UnicodeDecodeError that the OP is reporting. So either I need more
coffee or there is something else going on here that hasn't come to
light yet.

-- 
Carsten Haese
http://informixdb.sourceforge.net


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

Re: How does unicode() work?

[Carsten Haese]

On Wed, 2008-01-09 at 15:33 +0100, Fredrik Lundh wrote:
 When mixing Unicode with byte strings, Python attempts to decode the 
 byte string, not encode the Unicode string.

Ah, I did not realize that. I never mix Unicode and byte strings in the
first place, and now I know why. Thanks for clearing that up.

-- 
Carsten Haese
http://informixdb.sourceforge.net


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

Re: How does unicode() work?

[John Machin]

On Jan 10, 1:55 am, Carsten Haese [EMAIL PROTECTED] wrote:
 On Wed, 2008-01-09 at 15:33 +0100, Fredrik Lundh wrote:
  When mixing Unicode with byte strings, Python attempts to decode the
  byte string, not encode the Unicode string.

 Ah, I did not realize that. I never mix Unicode and byte strings in the
 first place, and now I know why. Thanks for clearing that up.


When mixing unicode strings with byte strings, Python attempts to
decode the str object to unicode, not encode the unicode object to
str. This is fine, especially when compared with the alternative, so
long as the str object is (loosely) ASCII. If the str object contains
a byte such that ord(byte)  127, an exception will be raised.

When mixing floats with ints, Python attempts to decode the int to
float, not encode the float to int. This is fine, especially when
compared with the alternative, so long as the int is not humungous. If
the int is huge, you will lose precision without any warning or any
exception being raised.

Do you avoid mixing ints and floats?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How does unicode() work?

[Robert Latest]

John Machin wrote:

 When mixing unicode strings with byte strings, Python attempts to
 decode the str object to unicode, not encode the unicode object to
 str.

Thanks for the explanation. Of course I didn't want to mix Unicode and Latin 
in one string, my snippet just tried to illustrate the point. I'm new to 
Python -- I came from C, and C gives a rat's ass about encoding. It just 
dumps bytes and that's that.

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

How does setup.py work?

[dxm]

I am a new comer to python.
I am wondering how setup.py works.
For example, I have a directory like this:
/
   setup.py
   mymodule.c

where setup.py is:

from distutils.core import setup, Extension

mod = Extension('mymodule', sources = ['mymodule.c'])

setup (name = 'Package',
   version = '1.0',
   description = 'This is a demo package',
   ext_modules = [mod])

The correct way to install the newly created extension module is to
type
python setup.py install instead of executing those statements in
python shell, isn't it ?
My question is how additional arguments like 'build', 'install' are
passed into python and how
can I install it from interactively from python shell

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

Re: How does setup.py work?

[Matias Surdi]

dxm escribió:
 I am a new comer to python.
 I am wondering how setup.py works.
 For example, I have a directory like this:
 /
setup.py
mymodule.c
 
 where setup.py is:
 
 from distutils.core import setup, Extension
 
 mod = Extension('mymodule', sources = ['mymodule.c'])
 
 setup (name = 'Package',
version = '1.0',
description = 'This is a demo package',
ext_modules = [mod])
 
 The correct way to install the newly created extension module is to
 type
 python setup.py install instead of executing those statements in
 python shell, isn't it ?
 My question is how additional arguments like 'build', 'install' are
 passed into python and how
 can I install it from interactively from python shell
 


Here you can read the documentation of setuptools , the package from 
where setup.py comes.

http://peak.telecommunity.com/DevCenter/setuptools

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

Re: How does setup.py work?

[Robert Kern]

dxm wrote:
 I am a new comer to python.
 I am wondering how setup.py works.
 For example, I have a directory like this:
 /
setup.py
mymodule.c
 
 where setup.py is:
 
 from distutils.core import setup, Extension
 
 mod = Extension('mymodule', sources = ['mymodule.c'])
 
 setup (name = 'Package',
version = '1.0',
description = 'This is a demo package',
ext_modules = [mod])
 
 The correct way to install the newly created extension module is to
 type
 python setup.py install instead of executing those statements in
 python shell, isn't it ?

Yes.

 My question is how additional arguments like 'build', 'install' are
 passed into python

Command-line arguments are passed into Python as the list sys.argv. Try running
the following script to explore this:

 sys_argv.py 
#!/usr/bin/env python
import sys
print sys.argv
#

[~]$ python sys_argv.py
['sys_argv.py']
[~]$ python sys_argv.py build
['sys_argv.py', 'build']
[~]$ python sys_argv.py build_ext --inplace install
['sys_argv.py', 'build_ext', '--inplace', 'install']

http://docs.python.org/lib/module-sys.html

Code inside setup() parses this list to determine what actions the user wants it
to take.

 and how
 can I install it from interactively from python shell

Generally speaking, you don't. distutils was not really designed for this use
case. There is no easy way to do this.

-- 
Robert Kern

I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth.
  -- Umberto Eco

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

Re: How does setup.py work?

[Robert Kern]

Matias Surdi wrote:

 Here you can read the documentation of setuptools , the package from 
 where setup.py comes.
 
 http://peak.telecommunity.com/DevCenter/setuptools

No, setup.py files are standard distutils. setuptools is a 3rd-party package
that extends distutils.

  http://docs.python.org/dist/dist.html

-- 
Robert Kern

I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth.
  -- Umberto Eco

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

Re: How does super() work?

[Gabriel Genellina]

En Fri, 31 Aug 2007 17:58:24 -0300, Lamonte Harris [EMAIL PROTECTED]  
escribi�:

 I've searched Google, and other search engines to try to find out how
 super() works.  Can someone explain in short detail how super() works?  I
 may and may not need to know this information, but it is good to know.

See http://www.python.org/download/releases/2.2.3/descrintro/#cooperation

-- 
Gabriel Genellina

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

Re: How does super() work?

[Michele Simionato]

 En Fri, 31 Aug 2007 17:58:24 -0300, Lamonte Harris [EMAIL PROTECTED]
 escribi?:

  I've searched Google, and other search engines to try to find out how
  super() works.  Can someone explain in short detail how super() works?  I
  may and may not need to know this information, but it is good to know.

You may also look at my ACCU lectures on advanced Python:
http://www.phyast.pitt.edu/~micheles/oxford-lectures.zip

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

Re: How does super() work?

[Gerardo Herzig]

Lamonte Harris wrote:

I've searched Google, and other search engines to try to find out how
super() works.  Can someone explain in short detail how super() works?  I
may and may not need to know this information, but it is good to know.

  

There is at least one explanation in the python.org site, among other 
topics related to super() usage:
http://www.python.org/download/releases/2.2.3/descrintro/#cooperation

Cheers,
Gerardo
-- 
http://mail.python.org/mailman/listinfo/python-list

How does super() work?

[Lamonte Harris]

I've searched Google, and other search engines to try to find out how
super() works.  Can someone explain in short detail how super() works?  I
may and may not need to know this information, but it is good to know.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How does xmlrpc work ?

[Marc 'BlackJack' Rintsch]

On Wed, 01 Aug 2007 05:32:14 +, [EMAIL PROTECTED] wrote:

 I am working on a system which used XMLRPC to communicate between
 hundreds of computer. One administrative computer keeps hundreds of
 xmlrpc instance of other computers.  I want to know if evey instance
 use a single connection and keep it alive forever OR create a new
 connection when a method is called and end it after the call is
 finished?

Every XMLRPC call uses its own HTTP connection that is closed after the
call is finished.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

How does xmlrpc work ?

[[EMAIL PROTECTED]]

Hi everyone
I am working on a system which used XMLRPC to communicate between
hundreds of computer. One administrative computer keeps hundreds of
xmlrpc instance of other computers.  I want to know if evey instance
use a single connection and keep it alive forever OR create a new
connection when a method is called and end it after the call is
finished?

Thank you

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

How does py2exe work?

[vasudevram]

Hi,

I recently checked out py2exe (on Windows). Looks good.
Was able to build an EXE out of one of my Python apps.

Wondering how it works? Does it actually compile the Python source of
your script into machine language, or does it do something more like
bundling the Python interpreter, the Python libraries and the script
itself, into a file?

Will look at the source code but would like to get some ideas ...

Thanks ...

Vasudev Ram
Dancing Bison Enterprises
Biz site: http://www.dancingbison.com
Blog on software innovation: http://jugad.livejournal.com
xtopdf: PDF creation/construction toolkit:
  http://www.dancingbison.com/products.html

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

Re: How does py2exe work?

[Thomas Jollans]

On Sunday 01 July 2007, vasudevram wrote:
 Wondering how it works? Does it actually compile the Python source of
 your script into machine language, or does it do something more like
 bundling the Python interpreter, the Python libraries and the script
 itself, into a file?

essentially, that's what it does.

-- 
  Regards,   Thomas Jollans
GPG key: 0xF421434B may be found on various keyservers, eg pgp.mit.edu
Hacker key http://hackerkey.com/:
v4sw6+8Yhw4/5ln3pr5Ock2ma2u7Lw2Nl7Di2e2t3/4TMb6HOPTen5/6g5OPa1XsMr9p-7/-6


signature.asc
Description: This is a digitally signed message part.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How does py2exe work?

[Wildemar Wildenburger]

Thomas Jollans wrote:
 On Sunday 01 July 2007, vasudevram wrote:
   
 Wondering how it works? Does it actually compile the Python source of
 your script into machine language, or does it do something more like
 bundling the Python interpreter, the Python libraries and the script
 itself, into a file?
 

 essentially, that's what it does.

   
Q: A or B?
A: Yes.

*nudgenudge*
/W
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How does py2exe work?

[vasudevram]

On Jul 2, 12:43 am, Wildemar Wildenburger [EMAIL PROTECTED]
wrote:
 Thomas Jollans wrote:
  On Sunday 01 July 2007, vasudevram wrote:

  Wondering how it works? Does it actually compile the Python source of
  your script into machine language, or does it do something more like
  bundling the Python interpreter, the Python libraries and the script
  itself, into a file?

  essentially, that's what it does.

 Q: A or B?
 A: Yes.

 *nudgenudge*
 /W

He should have said the 2nd way but thanks, I did guess what he
meant :-)

- Vasudev


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

How does os.walk work?

[[EMAIL PROTECTED]]

In the example from help(os.walk) it lists this:

from os.path import join, getsize
for root, dirs, files in walk('python/Lib/email'):
print root, consumes,
print sum([getsize(join(root, name)) for name in files]),
print bytes in, len(files), non-directory files
if 'CVS' in dirs:
dirs.remove('CVS')  # don't visit CVS directories

What I'm wondering is how does the dirs.remove('CVS') line prevent
os.walk from visiting that directory?  how does the walk function know
what you do to the dirs variable?  I tried looking at the code in
os.py but it wasn't clear to me there either.

Thanks,

Greg

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

Re: How does os.walk work?

[Gary Herron]

[EMAIL PROTECTED] wrote:
 In the example from help(os.walk) it lists this:

 from os.path import join, getsize
 for root, dirs, files in walk('python/Lib/email'):
 print root, consumes,
 print sum([getsize(join(root, name)) for name in files]),
 print bytes in, len(files), non-directory files
 if 'CVS' in dirs:
 dirs.remove('CVS')  # don't visit CVS directories

 What I'm wondering is how does the dirs.remove('CVS') line prevent
 os.walk from visiting that directory?  how does the walk function know
 what you do to the dirs variable?  I tried looking at the code in
 os.py but it wasn't clear to me there either.
   
Simple:  os.walk builds the list to contain all the subdirectories. 
After giving you a chance to modify that list, ow.walk then goes through
the list (whatever contents it has at that point) and visits any
subdirectory. 

I'd guess your trouble with understanding this has to do with wondering
how the modified list gets from your code back to os.walk.  But in fact
they are not two separate lists, but one list, passed by reference from
os.walk into your code. 

Gary Herron
 Thanks,

 Greg

   

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

Re: How does os.walk work?

[[EMAIL PROTECTED]]

On Jun 7, 5:13 pm, Gary Herron [EMAIL PROTECTED] wrote:
 Simple:  os.walk builds the list to contain all the subdirectories.
 After giving you a chance to modify that list, ow.walk then goes through
 the list (whatever contents it has at that point) and visits any
 subdirectory.

 I'd guess your trouble with understanding this has to do with wondering
 how the modified list gets from your code back to os.walk.  But in fact
 they are not two separate lists, but one list, passed by reference from
 os.walk into your code.

Thanks, that does make sense now.

-Greg


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

retrbinary ! how does it work ?

[[EMAIL PROTECTED]]

Hello dear community !

I'm a bit ashamed to ask such an easy question, but I didn't find my
answer on previous posts.
I'd like to copy files with FTP protocol in a subdirectory.
So far, my code look like that :

  import ftplib
  session = ftplib.FTP('222.33.44.55','usr','pwd')
  session.cwd('/')
  files = session.nlst()
  for file in files:
session.retrbinary('RETR '+file, open(file, 'wb').write)

It does work but the files are copied in the same directory as the
python file. And I would like to copy the file in this relative
directory :  ../archives
For example, if the python file is in this directory : C:\SCOR\Bat\,
the FTP files gotta be in C:\SCOR\archives\ .

Can anyone help me.

Thanks a lot by advance.

Yvan Blancmunier

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

Re: retrbinary ! how does it work ?

[Diez B. Roggisch]

[EMAIL PROTECTED] wrote:

 Hello dear community !
 
 I'm a bit ashamed to ask such an easy question, but I didn't find my
 answer on previous posts.
 I'd like to copy files with FTP protocol in a subdirectory.
 So far, my code look like that :
 
   import ftplib
   session = ftplib.FTP('222.33.44.55','usr','pwd')
   session.cwd('/')
   files = session.nlst()
   for file in files:
 session.retrbinary('RETR '+file, open(file, 'wb').write)
 
 It does work but the files are copied in the same directory as the
 python file. And I would like to copy the file in this relative
 directory :  ../archives
 For example, if the python file is in this directory : C:\SCOR\Bat\,
 the FTP files gotta be in C:\SCOR\archives\ .
 
 Can anyone help me.

The problem is your callback-function that you create like this:

open(file, 'wb').write

If all you pass here is file, where else than in the current working
directory do you expect files to appear?

Either provide a full destination path like this

open(os.path.join('../', file), 'wb').write

or change the current working directory beforehand, using os.cwd.

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

Re: retrbinary ! how does it work ?

[Gabriel Genellina]

En Thu, 01 Feb 2007 06:17:34 -0300, [EMAIL PROTECTED]  
[EMAIL PROTECTED] escribió:

 I'd like to copy files with FTP protocol in a subdirectory.
 So far, my code look like that :

   import ftplib
   session = ftplib.FTP('222.33.44.55','usr','pwd')
   session.cwd('/')
   files = session.nlst()
   for file in files:
 session.retrbinary('RETR '+file, open(file, 'wb').write)

(hmm, using file as a variable name is not a good idea, it hides the  
builtin type of the same name)

 It does work but the files are copied in the same directory as the
 python file. And I would like to copy the file in this relative
 directory :  ../archives
 For example, if the python file is in this directory : C:\SCOR\Bat\,
 the FTP files gotta be in C:\SCOR\archives\ .

Let's say, if the file name were abc.txt, you should open the output  
using this name: '../archives/abc.txt'
To build a path from its components, use os.path.join
So, replace open(file,... above, with  
open(os.path.join('../archives',file),...

-- 
Gabriel Genellina

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

Re: retrbinary ! how does it work ?

[[EMAIL PROTECTED]]

Thanks a lot Diez and Gabriel.
It works perfectly !
Have a nice day
Yvan

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

wxpython: how does EVT_IDLE work?

[John Salerno]

Quick question about the code below: I understand why the progress bar 
fills up at a steady pace when the mouse is idle over the frame; but 
why, when you move the mouse, does the progress bar speed up? Shouldn't 
it stop completely until the mouse is idle again?

Also, on a side note, I'm confused by the use of the word bevel and 
bezel. The methods seem to use bezel, but according to wxPython in 
Action, it's referring to the bevel of the border of the widget. Also, 
the book refers to a method called SetBevelWidth(), but the code shows 
it as SetBezelWidth() -- and only the latter works -- so what's the deal 
with these words?

Thanks!

--

import wx

class GaugeFrame(wx.Frame):

 def __init__(self):
 wx.Frame.__init__(self, None, -1, 'Gauge Example')
 panel = wx.Panel(self)
 self.count = 0
 self.gauge = wx.Gauge(panel, -1, 50, (20, 50), (250, 25))
 self.gauge.SetBevelFace(3)
 self.gauge.SetShadowWidth(3)
 self.Bind(wx.EVT_IDLE, self.OnIdle)

 def OnIdle(self, event):
 self.count += 1
 if self.count = 50:
 self.count = 0
 self.gauge.SetValue(self.count)

if __name__ == '__main__':
 app = wx.App(redirect=False)
 GaugeFrame().Show()
 app.MainLoop()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: wxpython: how does EVT_IDLE work?

[John Salerno]

John Salerno wrote:
 Quick question about the code below: I understand why the progress bar 
 fills up at a steady pace when the mouse is idle over the frame; but 
 why, when you move the mouse, does the progress bar speed up? Shouldn't 
 it stop completely until the mouse is idle again?

Ok, now I'm really confused. I just ran the code again and this time it 
*doesn't* increase the progress bar when the mouse is idle, and it only 
increases when I move it. This wasn't the behavior just a few minutes 
ago, and I didn't change anything! What's going on?



 self.gauge.SetBevelFace(3)

Should be 'Bezel'.
-- 
http://mail.python.org/mailman/listinfo/python-list