Re: True == 1 weirdness

2015-09-19 Thread Gregory Ewing 

Random832 wrote:

I'm disputing that chained comparisons are used for the particular
combinations that I am actually arguing should not be used in python.
Such as a < b > c or a != b != c  [whereas a may or may not be equal to
c]


I can't remember offhand seeing a != b != c written by a
mathematician, but if I did, I would suspect that he
*intended* it to imply a != c, even if that's not a strict
logical consequence of the notation.

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

Add items from a python list to a javascript array

2015-09-19 Thread Darryl Doherty 
I have a kiosk for digital signage which has a html index file with a 
javascript which rotates through other html files using iframe at timed 
intervals. What I want to do is edit the array in the index file with Python to 
add and remove the HTML file paths from the array. I have a list of all file 
paths in the python list, so I want to select a path from the list and add it 
to the javascript array. In addition I want to be able to use python to remove 
file paths from the array when needed. I'm new to Python so some code examples 
would be appreciated. Thanks.

File paths:
Python script: '/users/admin/desktop/update.py
HTML file: '/users/admin/desktop/msa0007/content/index.html'
Other html files live in sub directories under 
'/users/admin/desktop/msa0007/content/'

Python List:
mylist = ['/users/admin/desktop/msa0007/content/test1/test1.html', 
'/users/admin/desktop/msa0007/content/test2/test2.html', 
'/users/admin/desktop/msa0007/content/test3/test3.html', 
'/users/admin/desktop/msa0007/content/test4/test4.html', 
'/users/admin/desktop/msa0007/content/test5/test5.html', 
'/users/admin/desktop/msa0007/content/test6/test6.html']

Javascript Array:
var frames = Array('/users/admin/desktop/msa0007/content/test1/test1.html', 
'/users/admin/desktop/msa0007/content/test2/test2.html', 
'/users/admin/desktop/msa0007/content/test3/test3.html', 
'/users/admin/desktop/msa0007/content/test4/test4.html');


Index.html:
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>



Changing Pages... Please Wait

var frames = Array('/users/admin/desktop/msa0007/content/test1/test1.html', 
'/users/admin/desktop/msa0007/content/test2/test2.html', 
'/users/admin/desktop/msa0007/content/test3/test3.html', 
'/users/admin/desktop/msa0007/content/test4/test4.html');
var i = 0, len = frames.length;
function ChangeSrc() {
document.getElementById('frame').src = frames[i];
if (i >= len-1) { i = 0 } else { i++; };
setTimeout('ChangeSrc()', (15 * 1000));

}
window.onload = ChangeSrc;






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

Re: Add items from a python list to a javascript array

2015-09-19 Thread Denis McMahon 
On Sat, 19 Sep 2015 00:25:20 -0700, Darryl Doherty wrote:

> I have a kiosk for digital signage which has a html index file with a
> javascript which rotates through other html files using iframe at timed
> intervals. What I want to do is edit the array in the index file with
> Python to add and remove the HTML file paths from the array. I have a
> list of all file paths in the python list, so I want to select a path
> from the list and add it to the javascript array. In addition I want to
> be able to use python to remove file paths from the array when needed.
> I'm new to Python so some code examples would be appreciated. Thanks.

I'm going to assume that the whole web page is being generated by python 
code with the web server, and that the list of files is available in the 
python code at the time of web page generation.

First of all, you need to create a python list of the file names to use. 
This will use whatever the current data is when the web page is generated.

Secondly, you need to write this list to a suitable javascript variable 
when you construct the web page. Assuming that all the file paths are 
standard ascii with no spaces etc in them, say you have a python list 
like this:

Here is a very simple code example for a method (and there are others) of 
embedding such a list of paths held in python within a javascript 
variable inside a script element in a web page:

#!/usr/bin/python

files = ["/a/a.htm", "/a/b.htm", "/a/c.htm"]

page = "\n"

fmt = "var frames=Array({});\n"

page += fmt.format(",".join(map(lambda x:'"'+x+'"', files)))

page += "\n"

print page


-- 
Denis McMahon, [email protected]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Shutting down a cross-platform multithreaded app

2015-09-19 Thread James Harris 
"Chris Angelico"  wrote in message 
news:[email protected]...
On Sat, Sep 19, 2015 at 3:17 AM, James Harris 
 wrote:
Needless to say, on a test Windows machine AF_UNIX is not present. 
The only

cross-platform option, therefore, seems to be to use each subthread's
select()s to monitor two AF_INET sockets: the one to the client and a
control one from the master thread. I would seem to need IP socket 
pairs
between the master thread and the subthreads. If the master thead 
receives a

shutdown signal it will send a shutdown command to each subthread.

The above seems logical but would use quite a few IP sockets. I 
cannot think

of a better way, though. Any comments on the ideas above?


If you're using select() to monitor the sockets, you don't actually
then have to _do_ anything with the shutdown socket. You could have a
single socket that sends the shutdown signal to all your workers.


I don't understand how a single socket could send the signal to all the 
workers. I did consider some form of multicast but thought it too 
complicated (and possibly infeasible).


Re. not understanding the single sending socket idea that you mention 
perhaps I had better explain a bit of what I had in mind:


1. A worker thread would have a TCP socket connection to its client, and 
another socket for communicating with the master. That second socket has 
to be AF_INET for portability. It could be TCP or UDP. A connected UDP 
socket may be most appropriate and seems worth trying.


2. If something happens to the master thread so that it determines that 
the application should shut down it would iterate over the sockets to 
the workers and tell each one to shut down. It would then shut itself 
down. (Am not sure at the moment whether to wait for the worker 
threads.)


3. A worker thread, being told to shutdown (basically a single byte 
received from the master thread) would tell its client to close the TCP 
connection and then it would wait a little while for it to do so - maybe 
a second or two. When the client closes the TCP connection (or the 
timeout wait period expires) the worker thread will close its end and 
exit.



Bear in mind, though, that Windows has no protection against other
processes shutting you down. You can restrict it to 127.0.0.1 (of
course) but any program running on the same computer as the server -
regardless of user permissions etc - will be able to connect to your
sockets.


I was thinking of a connected UDP socket. That way, AIUI, at least in 
the absence of forged datagrams, only the master thread will be able to 
communicate with the worker, due to connected UDP sockets demulitplexing 
datagrams based on their source as well as their destination, i.e. on a 
5-tuple (UDP, source IP, source port, destination IP, destination port).



So it might be best to do something like this (all on the
main thread):

1) Open a listening socket
2) Connect to the listening socket
3) Accept a connection
4) Close the original listening socket
5) Spin off all your threads, passing them the socket from step 2
6) To terminate them all, write a byte to the socket from step 3.


That sounds similar to what I had in mind but I am not sure why you 
would close the listening socket. Connections could come in at any time 
and threads could therefore be needed at any time so I was thinking that 
the master thread (the one with the listening TCP socket) would just sit 
waiting for new connection requests (or an interrupting signal).


In reality, due to Windows not recognising signals while in the accept() 
call I think there would be a real master thread and a listening thread 
but I have omitted that in the descriptions above. As far as the normal 
worker threads are concerned they would be ready to be told to shut down 
by the listening thread, and it would be ready to be told to shut down 
by the master thread. Still with me? ;-)



This will make it difficult for ordinary userspace code to mess with
you. It'd still be possible, I think, for something with raw sockets
access to feign a termination signal; I have no idea what protections
Windows offers you there.


Yes, something which could forge a packet could tell a worker to close 
down. I don't think there's any significant problem here, thought, 
because:


* other programs are similarly vulnerable to forged packets
* the only forgery effect is to tell a worker thread to stop - not a big 
loss

* the shutdown protocol would/should cause the client to re-request
* a forger would have to know the specific port number used by the 
master thread to communicate with that particular worker, and the port 
number that worker was using.


Overall, I think it would be more than robust enough.

Notwithstanding your comment about a single socket, above, no one seems 
so far to have objected to the number of sockets this would need, which 
was my main concern, so that's good!


James

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

Re: Shutting down a cross-platform multithreaded app

2015-09-19 Thread James Harris 


"Laura Creighton"  wrote in message 
news:[email protected]...
In a message of Fri, 18 Sep 2015 20:09:19 +0100, "James Harris" 
writes:

Set the daemon flag on the worker threads, so when the main thread
exits, the workers also exit.


Interesting idea, and I did not know that a *thread* could be a 
daemon.

Unfortunately, I think what you suggest would kill the threads stone
dead and not allow them to close connections.


Can you stick your worker threads into a Queue.  When the main thread 
exits

have it tell the queue to clean itself up?

see:
http://code.activestate.com/recipes/82965-threads-tkinter-and-asynchronous-io/

The main thread doesn't have to be a gui ...

(but the author of that recipe and I are now drunkly celebrating a 
birthday

so maybe I ought not to be posting this idea ...)


:-)

I am not sure. The polling every 100ms or similar in periodicCall() is 
something I want to avoid. I think I have a way to do this without any 
polling.


James

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

Re: Shutting down a cross-platform multithreaded app

2015-09-19 Thread Chris Angelico 
On Sat, Sep 19, 2015 at 7:49 PM, James Harris  wrote:
> "Chris Angelico"  wrote in message
> news:[email protected]...
>>
>> On Sat, Sep 19, 2015 at 3:17 AM, James Harris 
>> wrote:
>>>
>>> Needless to say, on a test Windows machine AF_UNIX is not present. The
>>> only
>>> cross-platform option, therefore, seems to be to use each subthread's
>>> select()s to monitor two AF_INET sockets: the one to the client and a
>>> control one from the master thread. I would seem to need IP socket pairs
>>> between the master thread and the subthreads. If the master thead
>>> receives a
>>> shutdown signal it will send a shutdown command to each subthread.
>>>
>>> The above seems logical but would use quite a few IP sockets. I cannot
>>> think
>>> of a better way, though. Any comments on the ideas above?
>>
>>
>> If you're using select() to monitor the sockets, you don't actually
>> then have to _do_ anything with the shutdown socket. You could have a
>> single socket that sends the shutdown signal to all your workers.
>
>
> I don't understand how a single socket could send the signal to all the
> workers. I did consider some form of multicast but thought it too
> complicated (and possibly infeasible).

The way I'm describing it, the workers never actually read from the
socket. Once that socket becomes readable, they immediately shut down,
without making the socket no-longer-readable.

>> Bear in mind, though, that Windows has no protection against other
>> processes shutting you down. You can restrict it to 127.0.0.1 (of
>> course) but any program running on the same computer as the server -
>> regardless of user permissions etc - will be able to connect to your
>> sockets.
>
>
> I was thinking of a connected UDP socket. That way, AIUI, at least in the
> absence of forged datagrams, only the master thread will be able to
> communicate with the worker, due to connected UDP sockets demulitplexing
> datagrams based on their source as well as their destination, i.e. on a
> 5-tuple (UDP, source IP, source port, destination IP, destination port).

TCP sockets also work on that set of five. That's why I suggested a
pre-connected TCP socket, with the original listening socket closed.

(And as mentioned, Python 3.5 supports socketpair() on Windows. That
would definitely be the best option.)

> That sounds similar to what I had in mind but I am not sure why you would
> close the listening socket. Connections could come in at any time and
> threads could therefore be needed at any time so I was thinking that the
> master thread (the one with the listening TCP socket) would just sit waiting
> for new connection requests (or an interrupting signal).

TCP sockets work on the basis of a master socket and any number of
spawned sockets. The master is what gives you an open port; each
spawned socket represents one connection with one client. Once you
have an established connection, the master should be able to be closed
without disrupting that. No other process will be able to connect to
you, but you'll still be able to use one end of the socket to make the
other end readable.

>> This will make it difficult for ordinary userspace code to mess with
>> you. It'd still be possible, I think, for something with raw sockets
>> access to feign a termination signal; I have no idea what protections
>> Windows offers you there.
>
>
> Yes, something which could forge a packet could tell a worker to close down.
> I don't think there's any significant problem here, thought, because:
>
> * other programs are similarly vulnerable to forged packets
> * the only forgery effect is to tell a worker thread to stop - not a big
> loss
> * the shutdown protocol would/should cause the client to re-request
> * a forger would have to know the specific port number used by the master
> thread to communicate with that particular worker, and the port number that
> worker was using.
>
> Overall, I think it would be more than robust enough.

With UDP, any process that can send a UDP packet can flood the system
with them until your workers shut down. You wouldn't even notice until
it succeeds. With TCP, at least an attacker would need raw socket
access. It's still not as protected as a Unix domain socket, but it's
a bit harder for someone to do.

> Notwithstanding your comment about a single socket, above, no one seems so
> far to have objected to the number of sockets this would need, which was my
> main concern, so that's good!

Sure. Sockets are pretty cheap. Even if you had one for every worker,
there's room for you to have thousands (maybe tens of thousands) of
workers without a problem. I think you'll run into other scaling
problems with that many workers on one computer :)

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

Re: Shutting down a cross-platform multithreaded app

2015-09-19 Thread James Harris 
"Chris Angelico"  wrote in message 
news:[email protected]...
On Sat, Sep 19, 2015 at 7:49 PM, James Harris 
 wrote:

"Chris Angelico"  wrote in message
news:[email protected]...


...


If you're using select() to monitor the sockets, you don't actually
then have to _do_ anything with the shutdown socket. You could have 
a

single socket that sends the shutdown signal to all your workers.



I don't understand how a single socket could send the signal to all 
the

workers. I did consider some form of multicast but thought it too
complicated (and possibly infeasible).


The way I'm describing it, the workers never actually read from the
socket. Once that socket becomes readable, they immediately shut down,
without making the socket no-longer-readable.


Understood. Good idea. Initial thoughts on it: Would work for threads. 
Would save on the number of sockets required. Would not work for 
processes if the model was ever changed. Would make it easier for rogue 
packets to shut a worker down. Would not allow any way to distinguish 
between shutdown priorities (not something I have mentioned). Definitely 
feasible. I'll keep it in mind.



Bear in mind, though, that Windows has no protection against other
processes shutting you down. You can restrict it to 127.0.0.1 (of
course) but any program running on the same computer as the server -
regardless of user permissions etc - will be able to connect to your
sockets.


...

That sounds similar to what I had in mind but I am not sure why you 
would

close the listening socket. Connections could come in at any time and
threads could therefore be needed at any time so I was thinking that 
the
master thread (the one with the listening TCP socket) would just sit 
waiting

for new connection requests (or an interrupting signal).


TCP sockets work on the basis of a master socket and any number of
spawned sockets. The master is what gives you an open port; each
spawned socket represents one connection with one client. Once you
have an established connection, the master should be able to be closed
without disrupting that. No other process will be able to connect to
you, but you'll still be able to use one end of the socket to make the
other end readable.


Agreed but I need the listening socket to remain open and listening for 
new connections (at least until the whole program is told to shut down).



This will make it difficult for ordinary userspace code to mess with
you. It'd still be possible, I think, for something with raw sockets
access to feign a termination signal; I have no idea what 
protections

Windows offers you there.



Yes, something which could forge a packet could tell a worker to 
close down.

I don't think there's any significant problem here, thought, because:

* other programs are similarly vulnerable to forged packets
* the only forgery effect is to tell a worker thread to stop - not a 
big

loss
* the shutdown protocol would/should cause the client to re-request
* a forger would have to know the specific port number used by the 
master
thread to communicate with that particular worker, and the port 
number that

worker was using.

Overall, I think it would be more than robust enough.


With UDP, any process that can send a UDP packet can flood the system
with them until your workers shut down. You wouldn't even notice until
it succeeds.


Is that true? You seem to be describing a non-forged attack but to get 
the source UDP port right wouldn't the attacker have to be runing on the 
same machine *and* to bind to the same port that the machine had 
allocated to my program? I might be wrong but I don't think the UDP 
stack would allow the same port to be bound again before the original 
had been closed.



With TCP, at least an attacker would need raw socket
access. It's still not as protected as a Unix domain socket, but it's
a bit harder for someone to do.

Notwithstanding your comment about a single socket, above, no one 
seems so
far to have objected to the number of sockets this would need, which 
was my

main concern, so that's good!


Sure. Sockets are pretty cheap. Even if you had one for every worker,
there's room for you to have thousands (maybe tens of thousands) of
workers without a problem. I think you'll run into other scaling
problems with that many workers on one computer :)


Let's see. If I stick with my original plan then each worker would have 
a TCP socket and a UDP socket. The "listener" thread would have its 
single listening TCP socket plus it would have a UDP socket for each 
worker thread. Total of three sockets per worker, two of which would be 
UDP sockets with port numbers assigned and thus consumed.


If I go with a single "shutdown socket" then I would have just one 
socket per worker. That would use fewer sockets, for sure.


James

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

Re: Adding PEP 495 support to dateutil

2015-09-19 Thread Alexander Belopolsky 
[Tim Peters]
>
> I think acceptance of 495 should be contingent upon
> someone first completing a fully functional (if not releasable)
> fold-aware zoneinfo wrapping.


[Alexander Belopolsky]
>
> I am making all development public early on and hope to see code reviews
and pull requests from interested parties.  Pull requests with additional
test cases are most welcome.


I've made some additional progress in my dateutil fork [1].  The tzfile
class is now fold-aware.  The tzfile implementation of tzinfo takes the
history of local time type changes from a binary zoneinfo file. These files
are installed on the majority of UNIX platforms.

More testing is needed, but I think my fork is now close to meeting Tim's
challenge.

Please note that you need to run the modified  dateutil fork [1] code under
PEP 495 fork of CPython. [2]

[1]: https://github.com/abalkin/dateutil/tree/pep-0495
[2]: https://github.com/abalkin/cpython
-- 
https://mail.python.org/mailman/listinfo/python-list

Hello

2015-09-19 Thread moon khondkar 
Hello I have problem with python installation.I downloaded python 3.5 but I 
cannot use it on my computer.I can not open the idle. I get something like 
saying "users\local settings\Application 
data\programs\python\python35-32\pythonw.exe is not valid win32 application. 
Thanks that will be help if you can solve this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Determining version of OpenSSL linked against python?

2015-09-19 Thread svalleru 
AFAIK, there is no version variable for python2.6 ssl module but here a tip:

Look for libeat32.dll (usually under Python2.6.1/Lib/site-packages), grep
for 'OpenSSL'
and you will see something like the following which will have the version
string:
-
:
SSLv3 part of OpenSSL 0.9.8d 28 Sep 2006
:


cheers



--
View this message in context: 
http://python.6.x6.nabble.com/Determining-version-of-OpenSSL-linked-against-python-tp485p5171962.html
Sent from the Python - python-list mailing list archive at Nabble.com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Writing a module to abstract a REST api

2015-09-19 Thread Sven R. Kunze 

Hi Joseph,

the basic wiring instances together is done via the assignment operator: 
"=". Like: queue._api = foo. Now, the "queue" knows about its API instance.


Question now is, when do you do "="?

On 18.09.2015 23:43, Joseph L. Casale wrote:

This is where I am going, but how do you perform dependency injection
in Python?


I am uncertain how large the application you want to build is supposed 
to be. I would definitely would start with less code (tighter coupled) 
which is easier to maintain in the first run.


But if you are interesting the DI in Python in general, I think you 
would love to read those two resources:


http://www.aleax.it/yt_pydi.pdf
http://code.activestate.com/recipes/413268/

I am not saying you shouldn't do DI, but it's easier to tight-couple 
things and make them more flexible in the aftermath *when finally you 
know where you application is going*. Otherwise, it might turn out to be 
a waste of resources.



It's perfectly fine to add a "secret" API instance to the object. It's
called aspect-oriented programming. You remove the aspect of how to
correctly manage an API instance and put that knowledge into a separate
piece of code. *thumbs up*

Yea, I am glad you agree:) Its a model I certainly subscribe to. I just don't
know how to make the disparate case "know" of the foo instance when
foo didn't instantiate it (which gives the injection opportunity).


As usual, somebody *needs**to know*. So, if the first version is only 
working hard-coupled because foo instantiated the queues, the second 
version then would, for example, assign the APIWrapper class instead of 
an APIWrapper instance to the _api attribute of all queue instances. The 
class could then work as a lookup/factory method*.***


If that is still not flexible enough and you find Queue and APIWrapper 
is still too much coupled, you can then refactor that out into a third 
module which is responsible only for wiring the instances together (or 
use the recipe).


But remember, you increase the complexity more and more and you better 
decide whether it's worth it, taking maintenance and future development 
into account.


I might reiterate here: I don't know of the scale of your application 
but if it is from scratch, you better start with tighter coupling and 
remove it bit by bit later, when you know where the journey goes AND if 
the tight coupling causes issues. It does not make sense to solve 
non-issues (at least economically).



That foo instance also serves of a starting point to make the GET type queries.

How would you go about making disparate case lookup a handle, especially
when I insist on placing all the objects in their files.


Why do you want to store the objects in files? Caching?


I know, tough to do in
Python, but its what I am used to.


That's alright. Your thinking will change the longer you use Python. You 
are going to strive for the simples (non-complex), shortest, direct and 
most comprehensive solution. It's a development; don't forget what 
you've learned but be open for the Python style. :)



Best,
Sven
-- 
https://mail.python.org/mailman/listinfo/python-list

windows 10

2015-09-19 Thread heidimtaylor 
I am using Windows 10.  I cannot find the Python (command line).  Do you know 
where I would find it?

Thank you,
Heidi

Sent from Mail for Windows 10
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Shutting down a cross-platform multithreaded app

2015-09-19 Thread Chris Angelico 
On Sat, Sep 19, 2015 at 8:48 PM, James Harris  wrote:
> "Chris Angelico"  wrote in message
> news:[email protected]...
>>
>> On Sat, Sep 19, 2015 at 7:49 PM, James Harris 
>> wrote:
>>>
>>> "Chris Angelico"  wrote in message
>>> news:[email protected]...
 If you're using select() to monitor the sockets, you don't actually
 then have to _do_ anything with the shutdown socket. You could have a
 single socket that sends the shutdown signal to all your workers.
>>>
>>>
>>>
>>> I don't understand how a single socket could send the signal to all the
>>> workers. I did consider some form of multicast but thought it too
>>> complicated (and possibly infeasible).
>>
>>
>> The way I'm describing it, the workers never actually read from the
>> socket. Once that socket becomes readable, they immediately shut down,
>> without making the socket no-longer-readable.
>
>
> Understood. Good idea. Initial thoughts on it: Would work for threads. Would
> save on the number of sockets required. Would not work for processes if the
> model was ever changed. Would make it easier for rogue packets to shut a
> worker down. Would not allow any way to distinguish between shutdown
> priorities (not something I have mentioned). Definitely feasible. I'll keep
> it in mind.

If you go to multiple processes, yeah, it probably wouldn't work *on
Windows*. On Unix, you can fork and have multiple processes with the
same socket. (It's very common to have, for instance, a subprocess's
stdin/stdout/stderr linked to pipes of some sort; the calling process
still retains control.)

It would be _harder_ for rogue packets to shut a worker down this way.

>> TCP sockets work on the basis of a master socket and any number of
>> spawned sockets. The master is what gives you an open port; each
>> spawned socket represents one connection with one client. Once you
>> have an established connection, the master should be able to be closed
>> without disrupting that. No other process will be able to connect to
>> you, but you'll still be able to use one end of the socket to make the
>> other end readable.
>
> Agreed but I need the listening socket to remain open and listening for new
> connections (at least until the whole program is told to shut down).

Not sure why. The sole purpose of this socket is to establish a
(single) socket pair used for the termination signals - nothing more.
You shouldn't need to listen for any new connections, even if you
spawn new workers.

>> With UDP, any process that can send a UDP packet can flood the system
>> with them until your workers shut down. You wouldn't even notice until
>> it succeeds.
>
> Is that true? You seem to be describing a non-forged attack but to get the
> source UDP port right wouldn't the attacker have to be runing on the same
> machine *and* to bind to the same port that the machine had allocated to my
> program? I might be wrong but I don't think the UDP stack would allow the
> same port to be bound again before the original had been closed.

UDP basically doesn't have protections like that. TCP does, and though
it _is_ possible to forge packets, it requires raw socket access. I
don't know what protections Windows has around that, but certainly a
software firewall should be able to notice that some program is
spewing raw packets.

> Let's see. If I stick with my original plan then each worker would have a
> TCP socket and a UDP socket. The "listener" thread would have its single
> listening TCP socket plus it would have a UDP socket for each worker thread.
> Total of three sockets per worker, two of which would be UDP sockets with
> port numbers assigned and thus consumed.
>
> If I go with a single "shutdown socket" then I would have just one socket
> per worker. That would use fewer sockets, for sure.

Yeah, it's pretty cheap either way. Your most scarce resource here
would be UDP port numbers, and there's 64K of those. That'd let you go
as far as 32K workers, and I don't think you can have that many
threads without saturating something somewhere else.

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

Local variables and thread safety

2015-09-19 Thread Saint Desmond 
Dear Team,
Kindly advise if variables declared within a function are thread safe.

I would like to share a snippet with you if you wouldn’t mind.

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

Re: windows 10

2015-09-19 Thread Joel Goldstick 
On Thu, Sep 17, 2015 at 8:16 PM,  wrote:

> I am using Windows 10.  I cannot find the Python (command line).  Do you
> know where I would find it?
>
>
>
> Thank you,
>
> Heidi
>
>
>
> Sent from Mail  for
> Windows 10
> Did you try googling "windows 10 command line"?  I did and found lots of
> links.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>


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

Re: windows 10

2015-09-19 Thread Mark Lawrence 

On 18/09/2015 01:16, [email protected] wrote:

I am using Windows 10.  I cannot find the Python (command line).  Do you
know where I would find it?

Thank you,

Heidi

Sent from Mail  for
Windows 10



Python doesn't come with Windows, you have to install it yourself.  What 
do you actually mean by "Python (command line)"?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: ConnectionError handling problem

2015-09-19 Thread Mark Lawrence 

On 19/09/2015 07:13, shiva upreti wrote:

I am learning python. I wrote a script using requests module.
The scripts runs fine for sometime, but after a while it hangs. When I press 
CTRL+C it shows ConnectionError even though I have included exception handling.
I am not sure as to why it cant handle ConnectionError when the script runs for 
a long time.

This is a part(causing issues) of the script I am running:

while(k<46656):
j=res[k]
url="http://172.16.68.6:8090/login.xml";   
query_args = {'mode':'191', 'username':str(i), 
'password':str(j), 'a':'1442397582010', 'producttype':'0'}

try:
r=requests.post(url, data=query_args)
except:
print "Connection error"
time.sleep(30)
continue

html=r.text
if(len(html) < 10):
continue

if("The system could not log you on" not in html):
print "hello"
filehandle=open("ids", "a")
filehandle.write(str(i)+'\n')
filehandle.write(str(j)+'\n')
filehandle.close()
break

k=k+1

Any help will be highly appreciated.



Never use a bare except in Python, always handle the bare minimum number 
of exceptions that you need to, in this case your ConnectionError.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Hello

2015-09-19 Thread Emile van Sebille 

On 9/17/2015 8:10 AM, moon khondkar wrote:

Hello I have problem with python installation.I downloaded python 3.5 but I cannot 
use it on my computer.I can not open the idle. I get something like saying 
"users\local settings\Application data\programs\python\python35-32\pythonw.exe 
is not valid win32 application. Thanks that will be help if you can solve this.



you might want to try activestate's version from
http://www.activestate.com/activepython/downloads

3.5 isn't available there yet, but it otherwise has
always been the easiest to install and get a more
complete level of windows compatibility.

emile

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

Re: Hello

2015-09-19 Thread Random832 
Dennis Lee Bieber  writes:
>   While Windows likes to stuff things in directories with spaces in them,
> I find third-party applications (especially those that are created for
> multiple OSes) work better when installed in directories that have no
> spaces...

Hey, don't put this on being created for multiple OSes. Unix and Mac
both supported spaces in filenames, at the OS level, *long* before
Windows did. Programs that break on encountering them are broken
everywhere.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Hello

2015-09-19 Thread Mark Lawrence 

On 19/09/2015 18:31, Dennis Lee Bieber wrote:

On Thu, 17 Sep 2015 16:10:55 +0100, moon khondkar 
declaimed the following:


Hello I have problem with python installation.I downloaded python 3.5 but I cannot 
use it on my computer.I can not open the idle. I get something like saying 
"users\local settings\Application data\programs\python\python35-32\pythonw.exe 
is not valid win32 application. Thanks that will be help if you can solve this.


Given that path, you have a very strangely configured Windows system...



All change with 3.5, so that looks about right for a default user 
installation, with "install for all users" going under "Program Files".


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

RE: Hello

2015-09-19 Thread Watson, Paul 
> Hello I have problem with python installation.I downloaded python 3.5 but
> I cannot use it on my computer.I can not open the idle. I get something like 
> saying
> "users\local settings\Application data\programs\python\python35-32\pythonw.exe
> is not valid win32 application. Thanks that will be help if you can solve 
> this.

Did you verify that the md5sum for the file you downloaded is correct?
https://www.python.org/downloads/release/python-350/

*-*-*- PRESBYTERIAN_HEALTHCARE_SERVICES_DISCLAIMER -*-*-*

This message originates from Presbyterian Healthcare Services or one of its 
affiliated organizations.
It contains information, which may be confidential or privileged, and is 
intended only for the
individual or entity named above. It is prohibited for anyone else to disclose, 
copy, distribute
or use the contents of this message. All personal messages express views solely 
of the sender, which are
not to be attributed to Presbyterian Healthcare Services or any of its 
affiliated organizations, and may not
be distributed without this disclaimer. If you received this message in error, 
please notify us immediately
at [email protected]. 

If you would like more information about Presbyterian Healthcare Services 
please visit our web site

http://www.phs.org


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

Re: Einstein's Riddle

2015-09-19 Thread Michael Torrie 
On 09/18/2015 03:51 AM, Nick Sarbicki wrote:
> On Fri, Sep 18, 2015 at 10:33 AM, Steven D'Aprano 
>> Time is relative. Perhaps the poster has been travelling at close to the
>> speed of light, and for him it is only a few minutes after the original
>> post was sent.
> 
> I prefer to think that it just took him this long to do it.

Probably what happened is some computer somewhere was finally rebooted
after 15 years of uptime, and this messages finally was processed after
years stuck in the queue.

I read once of a university that, upon decomissioning a mainframe, found
a job that had been in the queue for many years but had never run.
Probably some poor grad student's job.

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

Re: Local variables and thread safety

2015-09-19 Thread dieter 
Saint Desmond  writes:

> Dear Team,
> Kindly advise if variables declared within a function are thread safe.

In general, yes. However, there are exceptions.

First of all, "variable" is not the optimal term to use in this context.
In Python, a "variable" is nothing more than the binding of a name
to an object. The local binding in a function itself is thread safe; however,
operations on the bound object may not be thread safe.

For example, if the bound object comes from outside the function
(i.e. it is visible outside the function) then other threads could
modify it and those modifications conflict with each other or
modifications in this thread.

Another example would be the use of a locally defined function
(wich can access "variable"s defined in the enclosing function) as
a thread.


Look at Python's "threading" module to find general purpose utilities
to assure thread safety.

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

Re: Einstein's Riddle

2015-09-19 Thread m 
W dniu 20.09.2015 o 05:27, Michael Torrie pisze:
> On 09/18/2015 03:51 AM, Nick Sarbicki wrote:
>> > On Fri, Sep 18, 2015 at 10:33 AM, Steven D'Aprano 
>>> >> Time is relative. Perhaps the poster has been travelling at close to the
>>> >> speed of light, and for him it is only a few minutes after the original
>>> >> post was sent.
>> > 
>> > I prefer to think that it just took him this long to do it.
> Probably what happened is some computer somewhere was finally rebooted
> after 15 years of uptime, and this messages finally was processed after
> years stuck in the queue.

It's posted from @gmail account, and Gmail started near 2004

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

Re: Einstein's Riddle

2015-09-19 Thread Denis McMahon 
On Sat, 19 Sep 2015 21:27:47 -0600, Michael Torrie wrote:

> I read once of a university that, upon decomissioning a mainframe, found
> a job that had been in the queue for many years but had never run.
> Probably some poor grad student's job.

Somewhere there's a computer sitting in the corner of a Pentagon office 
that makes an unanswered modem call to a telephone somewhere once a week.

One day, someone will realise they have no idea why, and shut the 
computer off.

When the doomsday silo on the other end stops receiving it's weekly 
"everything is ok" message, it's going to nuke Beijing and Moscow .

(I really really really hope that this is indeed fiction!)

-- 
Denis McMahon, [email protected]
-- 
https://mail.python.org/mailman/listinfo/python-list