Re: Proposed new syntax

2017-08-22 Thread Rustom Mody
Since this erm… discussion has also brought in Haskell
and in this case, the name, the history etc are related I thought I'd mention 
the following

Around 2015 there was a major upheaval in the Haskell community around the
socalled FTP (foldable-traversable-prelude) controversy.

In many respects this controversy is analogous and even identical to this one
and the heat there was considerably more than this thread's storm-in-a-teaspoon

Mark Lentczner resigned as Haskell's release manager¹
which in the python world would be analogous to say Raymond Hettinger saying
“Python 3 is too much of a mess; I am going to stick to python 2.2”
Along with hims went other stalwarts like Lennart Augustsson and Eric Meijer's
widely acclaimed EdX course switched from haskell to hugs²
[which is like switching to python 1.6]

The controversy somewhat oversimplified is that foldr (reduce-from-right) was
foldr : (a → b → b) → b → [a] → b
It was changed to
foldr : Foldable 𝒯  ⇒  (a → b → b) → b → 𝒯 a → b

If we think of [a] as list_of_a and 𝒯 a as any general list-like interface
we would see the close parallel with the divergence of opinion on this thread

¹ 
http://haskell.1045720.n5.nabble.com/quot-Excuse-me-I-think-this-i-my-stop-quot-Resigning-from-the-Platform-td5819861.html
² 
https://www.reddit.com/r/haskell/comments/3ove2e/got_the_welcome_email_from_edx_fp101x_course_hugs/
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Proposed new syntax

2017-08-22 Thread Marko Rauhamaa
Gregory Ewing :

> Marko Rauhamaa wrote:
>> You will always have to step outside your formal system and resort to
>> hand-waving in a natural language.
>
> If the hand-waving is rigorous, this amounts to expanding your formal
> system by adding new axioms and/or rules to it.

Ultimately, it's not rigorous. You can add rigor to any number of
meta-levels, but on top of it all, you will need an informal "observer"
level. It's turtles all the way down.

For example, you can't have a set of all sets. The NBG set theory solves
the problem by introducing the concept of classes. You can have a class
of all sets. But you can't have a class of all classes.

> If the hand-waving is not rigorous, then you haven't really proved
> anything.

The mathematicians have stopped caring.

In fact, even if metamathematics were a closed, formal system, the best
it could achieve would be circular reasoning. That would still be
satisfactory and "convincing." However, no interesting system can prove
its own consistency (but it *can* prove it can't prove its own
consistency).

Recommended reading:

   https://www.amazon.com/Unprovability-Consistency-Essay-Moda
   l-Logic/dp/0521092973>


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


opencv tutorial links

2017-08-22 Thread Abdur-Rahmaan Janhangeer
dear mail list,

the only famous module i need to cover in python is open cv

can you drop some links or book recommendations apart from the official
website?

thanks,

Abdur-Rahmaan Janhangeer,
Mauritius
abdurrahmaanjanhangeer.wordpress.com
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Outlook csv Files

2017-08-22 Thread Abdur-Rahmaan Janhangeer
as someone who works with languages, this one seems quite manageable

 i assume you know how to deal with csv.
1 get the cell string
2 split at _
that will make you move around mpre easily as this separates in big chunk
3 for the first chunck, you might want to split at ,
4 and so on

Abdur-Rahmaan Janhangeer,
Mauritius
abdurrahmaanjanhangeer.wordpress.com

On 23 Aug 2017 03:34, "Gregory Grimes"  wrote:

> All,
>
> I have exported Remedy emails from Outlook to a csv file.  The issue is
> one cell, Body, has information in multiple lines:
>
> Subject,Body,From: (Name),From: (Address),From: (Type),To: (Name),To:
> (Address),To: (Type),CC: (Name),CC: (Address),CC: (Type),BCC: (Name),BCC:
> (Address),BCC: (Type),Billing Information,Categories,
> Importance,Mileage,Sensitivity
> INC00977622 Assigned : DBA - PKG1 : mbbanms0006.xxx.com - Alert,
> "Remedy Ticket Information
> 
> Date Open
> 08/09/17 12:10:57
> Ticket Number
> INC00977622  com/HPD%3AHelp+Desk/Default+User+View/?eid=INC00938650>
> Date Modified
> 08/09/17 12:10:57
> Category
> Status
> Assigned
> Priority
> High
> Short Description
> mbbanms0006.xxx.com - Alert
> User Information
> 
> User Name
> Remedy SPI
> User Login
> remedyspi
> User Phone
> ###
> User Email
> helpd...@xxx.com 
> User Department
> Staff Information
> 
> Staff Name
> Staff Login
> Staff Phone
> Staff Email
> 
> Staff Department
> DBA - PKG1
> Detailed Ticket Information
> 
> Incident Description
> Target : mb08dorb Type : Database Instance Host : mbbanms0006.xxx.com
> Info : A session was terminated at time/line number: Wed Aug 09 12:10:10
> 2017/84281. Metric=ORA-01000: maximum open cursors exceeded~ORA-01000:
> maximum open cursors exceeded~ORA-01000: maximum open cursors
> exceeded~ORA-01000: maximum open cursors exceeded~ORA-01000: maximum open
> cursors exceeded~ORA-01000: maximum open cursors exceeded~ORA-01000:
> maximum open cursors exceeded~ORA-01000: maximum open cursors
> exceeded~ORA-01000: maximum open cursors exceeded~ORA-01000: maximum open
> cursors exceeded~ORA-01000: maximum open cursors exceeded~ORA-01000:
> maximum open cursors exceeded~ORA-01000: maximum o
> Click Here to Access Remedy  “
>
> My question, what is the best way to parse the long Body string to extract
> information from this file for analysis?
>
> Thanks.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python list name in subject

2017-08-22 Thread Abdur-Rahmaan Janhangeer
ah thanks for the tip about me filtering them

thought the community liked core python style (mail lists where python dev
talk, discuss ideas,i.e. the ones where guido replies etc)

anyways thanks all

Abdur-Rahmaan Janhangeer,
Mauritius
abdurrahmaanjanhangeer.wordpress.com

On 22 Aug 2017 12:38, "Abdur-Rahmaan Janhangeer" 
wrote:

> Hi all,
>
> i am subscribed to different python lists and they put their names in the
> subject
> [name] subject
>
> hence i can at a glance tell which mail belongs to which list.
>
> A requests to admins to implement if possible
>
> Thank you!
>
>
> 
>  Garanti
> sans virus. www.avast.com
> 
> <#m_1748413376357339298_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python list name in subject

2017-08-22 Thread Ben Finney
Abdur-Rahmaan Janhangeer  writes:

> i am subscribed to different python lists and they put their names in the
> subject
> [name] subject

That's non-standard. The standard place for that information is the
“List-Id” field https://tools.ietf.org/html/rfc2919>.

> hence i can at a glance tell which mail belongs to which list.

Set up a filter on the specific value of the “List-Id” field, which is
set by any standards-conformant mailing list software.

Presto, you get any organisation you like based on that information; and
the rest of us don't get the Subject field cluttered.

-- 
 \   “Most people are other people. Their thoughts are someone |
  `\  else’s opinions, their lives a mimicry, their passions a |
_o__)   quotation.” —Oscar Wilde, _De Profundis_, 1897 |
Ben Finney

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


Re: Proposed new syntax

2017-08-22 Thread Ben Finney
Stephan Houben  writes:

> I have often done things like:
>
>   generate_id = itertools.count().__next__

Could you be convinced to instead do::

import functools
import itertools

generate_id = functools.partial(next, itertools.count())

-- 
 \“The right to search for truth implies also a duty; one must |
  `\  not conceal any part of what one has recognized to be true.” |
_o__) —Albert Einstein |
Ben Finney

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


Re: python list name in subject

2017-08-22 Thread Grant Edwards
On 2017-08-23, D'Arcy Cain  wrote:
> On 08/22/2017 10:14 AM, Grant Edwards wrote:
>> Please don't. It wastes space which is better used on the subject.  If
>> you want the mailing list prepended, then configure procmail (or
>> whatever) to do it for you.
>
> Better yet, put it in its own folder.

Even better, point a news client[1] at

   nntp://news.gmane.org/gmane.comp.python.general


[1] https://en.wikipedia.org/wiki/List_of_Usenet_newsreaders

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


Re: python list name in subject

2017-08-22 Thread D'Arcy Cain

On 08/22/2017 10:14 AM, Grant Edwards wrote:

Please don't. It wastes space which is better used on the subject.  If
you want the mailing list prepended, then configure procmail (or
whatever) to do it for you.


Better yet, put it in its own folder.

--
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:da...@vex.net VoIP: sip:da...@vybenetworks.com
--
https://mail.python.org/mailman/listinfo/python-list


Outlook csv Files

2017-08-22 Thread Gregory Grimes
All,

I have exported Remedy emails from Outlook to a csv file.  The issue is one 
cell, Body, has information in multiple lines:

Subject,Body,From: (Name),From: (Address),From: (Type),To: (Name),To: 
(Address),To: (Type),CC: (Name),CC: (Address),CC: (Type),BCC: (Name),BCC: 
(Address),BCC: (Type),Billing 
Information,Categories,Importance,Mileage,Sensitivity
INC00977622 Assigned : DBA - PKG1 : mbbanms0006.xxx.com - Alert,
"Remedy Ticket Information 

Date Open 
08/09/17 12:10:57 
Ticket Number 
INC00977622 

 
Date Modified 
08/09/17 12:10:57 
Category
Status
Assigned 
Priority
High 
Short Description 
mbbanms0006.xxx.com - Alert 
User Information 

User Name
Remedy SPI 
User Login
remedyspi
User Phone
###
User Email
helpd...@xxx.com  
User Department
Staff Information

Staff Name
Staff Login
Staff Phone
Staff Email
 
Staff Department
DBA - PKG1 
Detailed Ticket Information 

Incident Description
Target : mb08dorb Type : Database Instance Host : mbbanms0006.xxx.com Info 
: A session was terminated at time/line number: Wed Aug 09 12:10:10 2017/84281. 
Metric=ORA-01000: maximum open cursors exceeded~ORA-01000: maximum open cursors 
exceeded~ORA-01000: maximum open cursors exceeded~ORA-01000: maximum open 
cursors exceeded~ORA-01000: maximum open cursors exceeded~ORA-01000: maximum 
open cursors exceeded~ORA-01000: maximum open cursors exceeded~ORA-01000: 
maximum open cursors exceeded~ORA-01000: maximum open cursors 
exceeded~ORA-01000: maximum open cursors exceeded~ORA-01000: maximum open 
cursors exceeded~ORA-01000: maximum open cursors exceeded~ORA-01000: maximum o 
Click Here to Access Remedy  “

My question, what is the best way to parse the long Body string to extract 
information from this file for analysis?

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


Re: Proposed new syntax

2017-08-22 Thread Gregory Ewing

Marko Rauhamaa wrote:

You will always have
to step outside your formal system and resort to hand-waving in a
natural language.


If the hand-waving is rigorous, this amounts to expanding your
formal system by adding new axioms and/or rules to it.

If the hand-waving is not rigorous, then you haven't really
proved anything.

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


Re: requests.{get,post} timeout

2017-08-22 Thread Skip Montanaro
> You could provide both, but since one of them can be handled
> externally (with a thread, with a SIGALRM, or with some other sort of
> time limiting), the other one MUST be provided by the request.

Given the semantics of timeouts which percolate up from the socket
level, I agree with Chris. It has a particular meaning, that
implemented by the underlying socket layer. Unfortunately, the word
"timeout" can take on related (but different) meanings, depending on
context. We can discuss how to implement the timeout which means, "the
maximum amount of time it should take to transfer a chunk of content
from one end of the connection to the other", it's difficult to say
exactly where detecting such timeouts should live in the application's
network stack. That it might be tedious to implement correctly (I
suspect given their druthers, most people would prefer to leave
sleeping threading and signaling dogs lie) is kind of beside the
point.

Now that I have a firmer grasp of what timeout I do have (the socket
level per-read-or-write call timeout), I can decide how important it
is for me to implement the other.

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


Re: requests.{get,post} timeout

2017-08-22 Thread Chris Angelico
On Wed, Aug 23, 2017 at 5:06 AM, Jon Ribbens  wrote:
>> You can always add in the overall timeout separately. If the low-level
>> timeout were implemented that way, there would be no way to externally
>> add the other form of timeout. Therefore the only sane way to
>> implement the request timeout is a between-byte limit.
>
> I have no idea what you mean here. The only sane way to implement the
> request timeout is to provide both types of timeout.

You could provide both, but since one of them can be handled
externally (with a thread, with a SIGALRM, or with some other sort of
time limiting), the other one MUST be provided by the request.

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


Re: requests.{get,post} timeout

2017-08-22 Thread Chris Angelico
On Wed, Aug 23, 2017 at 5:10 AM, MRAB  wrote:
> On 2017-08-22 19:43, Chris Angelico wrote:
>>
>> On Wed, Aug 23, 2017 at 4:14 AM, Jon Ribbens 
>> wrote:
>>>
>>> On 2017-08-22, Chris Angelico  wrote:

 On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens 
 wrote:
>
> Yes. There is no timeout feature that can be used to limit the total
> time a 'requests' request takes. Some people might think that this is
> a serious flaw in the requests library that would need urgent
> rectification in order to make the library safe and useful to use in
> almost any situation, but the 'requests' developers are apparently not
> among those people.


 I'm not either. The idea of a timeout is to detect when something's
 completely not working, not to limit the overall time to process.
>>>
>>>
>>> We appear to have different understandings of the word "timeout".
>>> I think it means a time, which if it runs out, will stop the operation.
>>>
>>> I am somewhat surprised that anyone might have a different definition
>>> - not least because, from a human being's point of view, they care
>>> about the overall time something takes to happen and telling them that
>>> nothing's wrong because technically we are still "successfully" receiving
>>> the expected 10 kilobytes of data 3 hours later is unlikely to make
>>> them happy.
>>
>>
>> You start downloading a file from a web page. It stalls out.
>>
>> Is it merely slow, and continuing to wait will get you a result?
>>
>> Or has it actually stalled out and you should give up?
>>
>> The low-level timeout will distinguish between those. If you want a
>> high-level timeout across the entire job, you can do that too, but
>> then you have to figure out exactly how long is "too long". Let's say
>> you set a thirty-second timeout. Great! Now someone uses your program
>> on a midrange connection to download a 100MB file, or on a poor
>> connection to download a 5MB file, or on dial-up to download a 10KB
>> file. Data is constantly flowing, but at some point, the connection
>> just dies, because it's hit your timeout. This is EXTREMELY
>> frustrating.
>>
>> You can always add in the overall timeout separately. If the low-level
>> timeout were implemented that way, there would be no way to externally
>> add the other form of timeout. Therefore the only sane way to
>> implement the request timeout is a between-byte limit.
>>
> You might want to have a way of setting the minimum data rate in order to
> defend against a slowloris attack.

That assumes that that's an attack - it often isn't. But if that's
what you want, then add that as a separate feature - it's distinct
from a timeout.

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


Re: requests.{get,post} timeout

2017-08-22 Thread Jon Ribbens
On 2017-08-22, Chris Angelico  wrote:
> The low-level timeout will distinguish between those. If you want a
> high-level timeout across the entire job, you can do that too, but
> then you have to figure out exactly how long is "too long". Let's say
> you set a thirty-second timeout. Great! Now someone uses your program
> on a midrange connection to download a 100MB file, or on a poor
> connection to download a 5MB file, or on dial-up to download a 10KB
> file. Data is constantly flowing, but at some point, the connection
> just dies, because it's hit your timeout. This is EXTREMELY
> frustrating.

Sure, the right timeout to use depends on what your application is and
what it's doing.

> You can always add in the overall timeout separately. If the low-level
> timeout were implemented that way, there would be no way to externally
> add the other form of timeout. Therefore the only sane way to
> implement the request timeout is a between-byte limit.

I have no idea what you mean here. The only sane way to implement the
request timeout is to provide both types of timeout.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: requests.{get,post} timeout

2017-08-22 Thread MRAB

On 2017-08-22 19:43, Chris Angelico wrote:

On Wed, Aug 23, 2017 at 4:14 AM, Jon Ribbens  wrote:

On 2017-08-22, Chris Angelico  wrote:

On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens  wrote:

Yes. There is no timeout feature that can be used to limit the total
time a 'requests' request takes. Some people might think that this is
a serious flaw in the requests library that would need urgent
rectification in order to make the library safe and useful to use in
almost any situation, but the 'requests' developers are apparently not
among those people.


I'm not either. The idea of a timeout is to detect when something's
completely not working, not to limit the overall time to process.


We appear to have different understandings of the word "timeout".
I think it means a time, which if it runs out, will stop the operation.

I am somewhat surprised that anyone might have a different definition
- not least because, from a human being's point of view, they care
about the overall time something takes to happen and telling them that
nothing's wrong because technically we are still "successfully" receiving
the expected 10 kilobytes of data 3 hours later is unlikely to make
them happy.


You start downloading a file from a web page. It stalls out.

Is it merely slow, and continuing to wait will get you a result?

Or has it actually stalled out and you should give up?

The low-level timeout will distinguish between those. If you want a
high-level timeout across the entire job, you can do that too, but
then you have to figure out exactly how long is "too long". Let's say
you set a thirty-second timeout. Great! Now someone uses your program
on a midrange connection to download a 100MB file, or on a poor
connection to download a 5MB file, or on dial-up to download a 10KB
file. Data is constantly flowing, but at some point, the connection
just dies, because it's hit your timeout. This is EXTREMELY
frustrating.

You can always add in the overall timeout separately. If the low-level
timeout were implemented that way, there would be no way to externally
add the other form of timeout. Therefore the only sane way to
implement the request timeout is a between-byte limit.

You might want to have a way of setting the minimum data rate in order 
to defend against a slowloris attack.

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


Re: requests.{get,post} timeout

2017-08-22 Thread Chris Angelico
On Wed, Aug 23, 2017 at 4:31 AM, Grant Edwards
 wrote:
> On 2017-08-22, Chris Angelico  wrote:
>
>> """
>> Once your client has connected to the server and sent the HTTP
>> request, the read timeout is the number of seconds the client will
>> wait for the server to send a response. (Specifically, it's the number
>> of seconds that the client will wait between bytes sent from the
>> server. In 99.9% of cases, this is the time before the server sends
>> the first byte).
>> """
>>
>> "Between bytes" implies that you could have a long request, as long as
>> there's a keep-alive transmission every few seconds.
>
> Except a keep-alive transmission doesn't contain any bytes, so it
> shouldn't reset the timer.

If it's a TCP keep-alive, yes. But if you're looking at a long-poll
HTTP server, or a websocket, or you're proxying a different type of
connection, you can use a connection-level keep-alive to reset it.
I've often worked with TELNET, using an IAC GA or similar as a
keep-alive to get past stupid routers that drop connections after five
minutes of idleness..

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


Re: requests.{get,post} timeout

2017-08-22 Thread Chris Angelico
On Wed, Aug 23, 2017 at 4:14 AM, Jon Ribbens  wrote:
> On 2017-08-22, Chris Angelico  wrote:
>> On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens  
>> wrote:
>>> Yes. There is no timeout feature that can be used to limit the total
>>> time a 'requests' request takes. Some people might think that this is
>>> a serious flaw in the requests library that would need urgent
>>> rectification in order to make the library safe and useful to use in
>>> almost any situation, but the 'requests' developers are apparently not
>>> among those people.
>>
>> I'm not either. The idea of a timeout is to detect when something's
>> completely not working, not to limit the overall time to process.
>
> We appear to have different understandings of the word "timeout".
> I think it means a time, which if it runs out, will stop the operation.
>
> I am somewhat surprised that anyone might have a different definition
> - not least because, from a human being's point of view, they care
> about the overall time something takes to happen and telling them that
> nothing's wrong because technically we are still "successfully" receiving
> the expected 10 kilobytes of data 3 hours later is unlikely to make
> them happy.

You start downloading a file from a web page. It stalls out.

Is it merely slow, and continuing to wait will get you a result?

Or has it actually stalled out and you should give up?

The low-level timeout will distinguish between those. If you want a
high-level timeout across the entire job, you can do that too, but
then you have to figure out exactly how long is "too long". Let's say
you set a thirty-second timeout. Great! Now someone uses your program
on a midrange connection to download a 100MB file, or on a poor
connection to download a 5MB file, or on dial-up to download a 10KB
file. Data is constantly flowing, but at some point, the connection
just dies, because it's hit your timeout. This is EXTREMELY
frustrating.

You can always add in the overall timeout separately. If the low-level
timeout were implemented that way, there would be no way to externally
add the other form of timeout. Therefore the only sane way to
implement the request timeout is a between-byte limit.

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


Re: requests.{get,post} timeout

2017-08-22 Thread Grant Edwards
On 2017-08-22, Chris Angelico  wrote:

> """
> Once your client has connected to the server and sent the HTTP
> request, the read timeout is the number of seconds the client will
> wait for the server to send a response. (Specifically, it's the number
> of seconds that the client will wait between bytes sent from the
> server. In 99.9% of cases, this is the time before the server sends
> the first byte).
> """
>
> "Between bytes" implies that you could have a long request, as long as
> there's a keep-alive transmission every few seconds.

Except a keep-alive transmission doesn't contain any bytes, so it
shouldn't reset the timer.

-- 
Grant Edwards   grant.b.edwardsYow! It's some people
  at   inside the wall!  This is
  gmail.combetter than mopping!

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


Re: requests.{get,post} timeout

2017-08-22 Thread Jon Ribbens
On 2017-08-22, Chris Angelico  wrote:
> On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens  
> wrote:
>> Yes. There is no timeout feature that can be used to limit the total
>> time a 'requests' request takes. Some people might think that this is
>> a serious flaw in the requests library that would need urgent
>> rectification in order to make the library safe and useful to use in
>> almost any situation, but the 'requests' developers are apparently not
>> among those people.
>
> I'm not either. The idea of a timeout is to detect when something's
> completely not working, not to limit the overall time to process.

We appear to have different understandings of the word "timeout".
I think it means a time, which if it runs out, will stop the operation.

I am somewhat surprised that anyone might have a different definition
- not least because, from a human being's point of view, they care
about the overall time something takes to happen and telling them that
nothing's wrong because technically we are still "successfully" receiving
the expected 10 kilobytes of data 3 hours later is unlikely to make
them happy.
-- 
https://mail.python.org/mailman/listinfo/python-list


Multiple try expect in a for loop

2017-08-22 Thread Ganesh Pal
Hello python friends,

I need a suggestion  on the below piece of code . I have for loop and I
need to do the below i.e create 100 of queue  ,open ,and append some data
to a data structure.   Is multiple try except the way to go or any other
idea's.

I feel  that there is a better way to  write those try except statement or
avoid it  . I am  a Linux user on python 2.7

def create_queue():
q_name = ""
q_fd = ""
for itr in range(1, 100):
q_name =  randomword(100)
print q_name
try:
q.create(q_name)
except OSError as e:
sys.stderr.write('Unable to create Queue %s: %s\n' % (q_name,
str(e)))
return False
try:
q_fd =  q.open(q_name); // Can I add multiple statement like
this ?
q.append(q_fd, randomword(100))
except OSError as e:
sys.stderr.write('Unable to open or append Queue %s: %s\n' %
(q_name, str(e)))
return False

return True


Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: requests.{get,post} timeout

2017-08-22 Thread Chris Angelico
On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens  wrote:
> On 2017-08-22, Skip Montanaro  wrote:
>> I'm using the requests module with timeouts to fetch URLs, for example:
>>
>> response = requests.get("http://www.google.com/";, timeout=10)
>>
>> I understand the timeout value in this case applies both to creating the
>> connection and fetching the remote content. Can the server dribble out the
>> content (say, one byte every few seconds) to avoid triggering the timeout,
>
> Yes. There is no timeout feature that can be used to limit the total
> time a 'requests' request takes. Some people might think that this is
> a serious flaw in the requests library that would need urgent
> rectification in order to make the library safe and useful to use in
> almost any situation, but the 'requests' developers are apparently not
> among those people.

I'm not either. The idea of a timeout is to detect when something's
completely not working, not to limit the overall time to process. If
you want that, you can do it locally, maybe with signal.alarm or a
thread or something.

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


Re: requests.{get,post} timeout

2017-08-22 Thread Skip Montanaro
> """
> Once your client has connected to the server and sent the HTTP
> request, the read timeout is the number of seconds the client will
> wait for the server to send a response. (Specifically, it's the number
> of seconds that the client will wait between bytes sent from the
> server. In 99.9% of cases, this is the time before the server sends
> the first byte).
> """
>
> "Between bytes" implies that you could have a long request, as long as
> there's a keep-alive transmission every few seconds.

Thanks, Chris. That appears to be what's going on.

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


Re: requests.{get,post} timeout

2017-08-22 Thread Jon Ribbens
On 2017-08-22, Skip Montanaro  wrote:
> I'm using the requests module with timeouts to fetch URLs, for example:
>
> response = requests.get("http://www.google.com/";, timeout=10)
>
> I understand the timeout value in this case applies both to creating the
> connection and fetching the remote content. Can the server dribble out the
> content (say, one byte every few seconds) to avoid triggering the timeout,

Yes. There is no timeout feature that can be used to limit the total
time a 'requests' request takes. Some people might think that this is
a serious flaw in the requests library that would need urgent
rectification in order to make the library safe and useful to use in
almost any situation, but the 'requests' developers are apparently not
among those people.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: requests.{get,post} timeout

2017-08-22 Thread Chris Angelico
On Wed, Aug 23, 2017 at 12:02 AM, Skip Montanaro
 wrote:
> I'm using the requests module with timeouts to fetch URLs, for example:
>
> response = requests.get("http://www.google.com/";, timeout=10)
>
> I understand the timeout value in this case applies both to creating the
> connection and fetching the remote content. Can the server dribble out the
> content (say, one byte every few seconds) to avoid triggering the timeout,
> or must the request be completed within ten seconds after the connection is
> successfully opened? My reading of the documentation here is inconclusive:
>
> http://docs.python-requests.org/en/master/user/advanced/#timeouts
>
> If you specify a single value for the timeout, like this:
>
> r = requests.get('https://github.com', timeout=5)
>
> The timeout value will be applied to both the connect and the read
> timeouts.
>
> Does "read timeout" imply the timeout applied to an individual read from
> the underlying socket? A quick glance at the code suggests that might be
> the case, but I got a bit lost in the urllib3 code which underpins the
> requests module.

"""
Once your client has connected to the server and sent the HTTP
request, the read timeout is the number of seconds the client will
wait for the server to send a response. (Specifically, it's the number
of seconds that the client will wait between bytes sent from the
server. In 99.9% of cases, this is the time before the server sends
the first byte).
"""

"Between bytes" implies that you could have a long request, as long as
there's a keep-alive transmission every few seconds.

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


Re: python list name in subject

2017-08-22 Thread Rick Johnson
Tim Chase wrote:
> Rick Johnson wrote:

[...]

> Checking mailing list headers...yep, the "forum-of-origin"
> type hint is already present in standards-compliant fashion
> defined by RFC4021[1]:
>
> [...]
> 
> Just need a mail client that knows about standards and
> isn't fettered. ;-)

Well, that pretty much disqualifies google groups. :-)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python list name in subject

2017-08-22 Thread Tim Chase
On 2017-08-22 08:21, Rick Johnson wrote:
> Grant Edwards wrote:
> > Abdur-Rahmaan Janhangeer wrote:  
> > > 
> > > Hi all,  i am subscribed to different python lists and
> > > they put their names in the subject [name] subject  hence
> > > i can at a glance tell which mail belongs to which list.
> > > A requests to admins to implement if possible  
> > 
> > Please don't. It wastes space which is better used on the
> > subject.  If you want the mailing list prepended, then
> > configure procmail (or whatever) to do it for you.  
> 
> Although, considering that the BDFL has now made type-hints
> an official part of the language, a "forum-of-origin" type-
> hint, may be more Pythonic than we care to realize. 

Checking mailing list headers...yep, the "forum-of-origin" type hint
is already present in standards-compliant fashion defined by
RFC4021[1]:

List-Id: General discussion list for the Python programming language
 
List-Unsubscribe: ,
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
 

Just need a mail client that knows about standards and isn't
fettered. ;-)

-tkc


[1] https://tools.ietf.org/html/rfc4021#section-2.1.31
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python list name in subject

2017-08-22 Thread Rick Johnson
Grant Edwards wrote:
> Abdur-Rahmaan Janhangeer wrote:
> > 
> > Hi all,  i am subscribed to different python lists and
> > they put their names in the subject [name] subject  hence
> > i can at a glance tell which mail belongs to which list.
> > A requests to admins to implement if possible
> 
> Please don't. It wastes space which is better used on the
> subject.  If you want the mailing list prepended, then
> configure procmail (or whatever) to do it for you.

Although, considering that the BDFL has now made type-hints
an official part of the language, a "forum-of-origin" type-
hint, may be more Pythonic than we care to realize. 

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


Re: Proposed new syntax

2017-08-22 Thread Chris Angelico
On Wed, Aug 23, 2017 at 1:12 AM, Stephan Houben
 wrote:
> Op 2017-08-22, Ian Kelly schreef :
>> Careful! Python's dunder methods are reserved for use by Python.
>> They're exposed so that we can override them. Calling them directly is
>> generally considered bad style. And in this case specifically, it's
>> not equivalent.
>
> Mmm, you are correct. That's kind of a deception, really.
>
> I have often done things like:
>
>   generate_id = itertools.count().__next__
>
> but I suppose that isn't OK either, then.

That one probably won't bite you, but that doesn't mean it's correct.

General rule of thumb: Dunders are for defining, not for calling.

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


Re: Proposed new syntax

2017-08-22 Thread Stephan Houben
Op 2017-08-22, Ian Kelly schreef :
> Careful! Python's dunder methods are reserved for use by Python.
> They're exposed so that we can override them. Calling them directly is
> generally considered bad style. And in this case specifically, it's
> not equivalent. 

Mmm, you are correct. That's kind of a deception, really.

I have often done things like:

  generate_id = itertools.count().__next__

but I suppose that isn't OK either, then.

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


Re: python list name in subject

2017-08-22 Thread Grant Edwards
On 2017-08-22, Abdur-Rahmaan Janhangeer  wrote:
> Hi all,
>
> i am subscribed to different python lists and they put their names in the
> subject
> [name] subject
>
> hence i can at a glance tell which mail belongs to which list.
>
> A requests to admins to implement if possible

Please don't. It wastes space which is better used on the subject.  If
you want the mailing list prepended, then configure procmail (or
whatever) to do it for you.

-- 
Grant Edwards   grant.b.edwardsYow! Hey, waiter!  I want
  at   a NEW SHIRT and a PONY TAIL
  gmail.comwith lemon sauce!

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


requests.{get,post} timeout

2017-08-22 Thread Skip Montanaro
I'm using the requests module with timeouts to fetch URLs, for example:

response = requests.get("http://www.google.com/";, timeout=10)

I understand the timeout value in this case applies both to creating the
connection and fetching the remote content. Can the server dribble out the
content (say, one byte every few seconds) to avoid triggering the timeout,
or must the request be completed within ten seconds after the connection is
successfully opened? My reading of the documentation here is inconclusive:

http://docs.python-requests.org/en/master/user/advanced/#timeouts

If you specify a single value for the timeout, like this:

r = requests.get('https://github.com', timeout=5)

The timeout value will be applied to both the connect and the read
timeouts.

Does "read timeout" imply the timeout applied to an individual read from
the underlying socket? A quick glance at the code suggests that might be
the case, but I got a bit lost in the urllib3 code which underpins the
requests module.

Thx,

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


Re: Proposed new syntax

2017-08-22 Thread Ian Kelly
On Tue, Aug 22, 2017 at 3:58 AM, Stephan Houben
 wrote:
> Op 2017-08-11, Paul Rubin schreef :
>> I don't think we need this since we have itertools.takewhile:
>>
>>   from operator import gt
>>   from functools import partial
>>   from itertools import takewhile
>>
>>   [x + 1 for x in takewhile(partial(gt,5), (0,1,2,999,3,4))]
>>
>
> No need for partial and gt.
>
>   [x + 1 for x in takewhile((5).__gt__, (0,1,2,999,3,4))]
>
> Basically, Haskell's infix opererator sections can often be
> translated into Python by attribute access to the bound method.

Careful! Python's dunder methods are reserved for use by Python.
They're exposed so that we can override them. Calling them directly is
generally considered bad style. And in this case specifically, it's
not equivalent. Example:

import functools
import operator

@functools.total_ordering
class PseudoInt(object):
def __init__(self, value):
self.value = value
def __eq__(self, other):
return self.value == other
def __lt__(self, other):
return self.value < other

>>> PseudoInt(5) > 2
True
>>> 5 > PseudoInt(2)
True
>>> 5 > PseudoInt(7)
False
>>> operator.gt(5, PseudoInt(7))
False
>>> (5).__gt__(PseudoInt(7))
NotImplemented
>>> bool((5).__gt__(PseudoInt(7)))
True


The last line is the reason why the rich comparison methods should
have been designed to raise NotImplementedException rather than return
NotImplemented, but it's too late to change that.
-- 
https://mail.python.org/mailman/listinfo/python-list


Free Beta Invite for new scripting/VM technology (some survey answers required)

2017-08-22 Thread Zak Fenton
Hi everyone!


I'm in the process of launching a business around a new scripting-related 
technology. It's not specific to Python users, but may be of interest to many 
of you, so I'd like to make sure Python users are represented in my initial 
market research.


It's a very short survey and should take less than five minutes to complete. In 
return, you'll get a chance to play with the first beta release as it becomes 
available over the coming months (however places in the beta program are 
limited, so availability cannot be guaranteed).


The survey is here (the last page allows you to opt in to the beta program):


https://www.surveymonkey.com/r/HTLLWTB


Thanks,

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


python list name in subject

2017-08-22 Thread Abdur-Rahmaan Janhangeer
Hi all,

i am subscribed to different python lists and they put their names in the
subject
[name] subject

hence i can at a glance tell which mail belongs to which list.

A requests to admins to implement if possible

Thank you!


Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Proposed new syntax

2017-08-22 Thread Pavol Lisy
On 8/21/17, Chris Angelico  wrote:
> On Mon, Aug 21, 2017 at 12:19 PM, MRAB  wrote:
>> On 2017-08-21 03:00, Steve D'Aprano wrote:
>>>
>>> On Fri, 18 Aug 2017 04:55 pm, Marko Rauhamaa wrote:
>>>
 Is a Python implementation
 allowed to parallelize or otherwise reorder the evaluation loop?
>>>
>>>
>>> No.
>>>
>> [snip]
>>
>> Well, I suppose an implementation _could_ parallelise, or whatever,
>> _provided that_ it gave the same result.
>
> In other words, it's allowed to parallelise, just as long as
> everything happens sequentially. With arbitrary expressions, one of
> them could affect another easily.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>


import multiprocessing
def square(param):
ret = param[0] * param[0]
param[1].put("%d is done" % param[0])
return ret

pool = multiprocessing.Pool(processes=3)
m = multiprocessing.Manager()
q = m.Queue()
squares = pool.map(square, ((i, q) for i in range(10)))
print(squares)  # ordered
print([q.get() for i in range(q.qsize())])  # unordered

[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
['0 is done', '2 is done', '1 is done', '3 is done', '4 is done', '5
is done', '7 is done', '6 is done', '8 is done', '9 is done']

You could collect result sequentially (ordered) but calculate it
parallel (unordered).
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python to call or start a fortran a.out

2017-08-22 Thread Rick Johnson
On Monday, August 21, 2017 at 11:31:48 AM UTC-5, Chet Buell wrote:
> Need some help with updating python to call or start a
> fortran a.out executable  The problem I am having is I have
> an old Fortran based model that I need to run, in the past
> the fortran was triggered through the following python
> code:
> 
> #run fortran
> x = commands.getoutput(path+'/a.out')
> 
> Since the commands.getoutput has been depreciated it will
> not run on the newly built server that will now host this
> model. I have manually confirmed that the compiled a.out
> does run and produces the files, but the problem I am
> having is in triggering it to run with python.  The answer
> is probably so easy it is obviously being overlooked, but I
> can not seem to find it.  Any suggestions or help would be
> greatly appreciated.

> TITLE: python to call or start a fortran a.out

Please do consider the title of your posts more carefully.

The title you chose here was unfortunate, as it will not
provide an intuitive link between the problem and the
solution, therefore, it is unlikely that someone with the
same _general_ problem, will benefit from this exchange in
the future.

The _general_ problem here had nothing to with Fortran, much
less a specific file or executable named "a.out". So a
better title would have been: "How to run an executable from
Python", or: "How to spawn a subprocess from Python and
capture the result". Or even: "How to poke my OS with a
sharp stick, using Python". Perhaps the last example was a
bit too generalized, i admit, but you get the point. :-)

A good template for composing questions on internet forums
is as follows:

  MESSAGE_TITLE: "A concise, generalization of the problem here..."

  MESSAGE_BODY: " An elaborate and specific explanation of the problem here..."

Mentioning "Fortran" and "a.out" in the body of the message,
would be fine.

One of the happy-accidents[1] of composing thoughtful
queries, is that, many times you will happen upon the answer
to your own question during the composition process, and
even if you don't, at least you will have a much better
chance of receiving prompt and quality responses by
following this template. So either way, it's a win-win.

[1] Think "Bob Ross" here. As his most important
contribution to society was that he taught us all a very
important lesson. Namely, that all accidents can be "happy
accidents". An eternal optimist, he was...
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Dataframe iterating question : 3 ways of calling a row and column

2017-08-22 Thread Pavol Lisy
On 8/21/17, zach.sm...@orthofi.com  wrote:
> I wouldn't say I'm a Python noob, but I wouldn't say I'm a Python expert
> either. I work in data science and use Pandas Dataframes a lot. My question
> is regarding the difference in calling out a specific row, column
> combination in a dataframe.
>
> I see 3 ways of doing this:
> (1) df.loc[row_ind, column_ind]
> (2) df.column_ind.loc[row_ind]
> (3) df[column_ind].loc[row_ind]
>
> where column_ind is the column name & row_ind is the named row index/row
> name in the dataframe.
>
> Can anyone enlighten me as to the differences between the above 3 methods of
> getting to the same cell in the dataframe?
> Are there speed differences?
> Is it simply a preference thing?
> Is there a PEP8 preferred way of doing this?
> Are there specific disadvantages to any of the methods?
>
> Thanks in advance.
> Zach

First of all I am not expert in pandas or python either. I write just
a few thoughts...

I don't think PEP-8 is about it.

df.column_id is calling __getattr__ where (after some checks)
df[column_id] is returned. So it is slower than df[column_id].

But if you are doing things in REPL you could probably be happy to use
tab completion to get column name.

Or if you are writing paper in (for example) jupyter notebook
readability of your formulas could count more than speed!

BTW. there are more ways to do it (and I could miss many others) ->

(4) df.column_id[row_ind]

(5) df.get_value(row_ind, column_ind)

(6) df.ix[row_ind, column_ind]

interestingly doc -
http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.ix.html
doesn't say it is deprecated (
http://pandas.pydata.org/pandas-docs/stable/whatsnew.html#deprecate-ix
)

Just quick stupid test (python 3.6.2, IPython 6.1.0, pandas 0.20.3)
gave me this results (sorted by speed):

df = pd.DataFrame(data=[[1, 2, 3], [4, 5, 6]], columns=['A',
'B', 'C'])

%timeit df.ix[1,0]  # this is deprecated!
188 µs ± 6.55 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

%timeit df.A.loc[1]
46.2 µs ± 908 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)

%timeit df['A'].loc[1]
42.6 µs ± 2 µs per loop (mean ± std. dev. of 7 runs, 1 loops each)

aa = df.A
%timeit aa[1]
16.6 µs ± 519 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)

%timeit df.iloc[1,0]
14.5 µs ± 92.2 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)

%timeit df.loc[1,'A']
13.8 µs ± 251 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)

%timeit df.ix[1,'A']  # this is deprecated!
8.68 µs ± 107 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)

%timeit df.get_value(1, 'A')
3.51 µs ± 133 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)

But I want to add that thinking about speed of getting one value could
be thinking in wrong direction because using built in functions could
be better.

I just test my stupid benchmark (and gave quite opposite result :P) ->

%timeit sum(df.sum())
150 µs ± 2.35 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

def tst():
summa = 0
for i in range(len(df)):
for j in df.columns:
summa += df.get_value(i, j)
return summa
%timeit tst()
37.6 µs ± 1.1 µs per loop (mean ± std. dev. of 7 runs, 1 loops each)

But with just a little bigger data frame it is 10x faster using built
in function! ->

df = pd.DataFrame(data=[[1+3*i, 2+3*i, 3+3*i]  for i in range(100)],
columns=['A', 'B', 'C'])

def tst():
summa = 0
for i in range(len(df)):
for j in df.columns:
summa += df.get_value(i, j)
return summa
%timeit tst()
1.67 ms ± 68.7 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

%timeit sum(df.sum())
151 µs ± 2.01 µs per loop (mean ± std. dev. of 7 runs, 1 loops each)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Proposed new syntax

2017-08-22 Thread Stephan Houben
Op 2017-08-11, Paul Rubin schreef :
> I don't think we need this since we have itertools.takewhile:
>
>   from operator import gt
>   from functools import partial
>   from itertools import takewhile
>
>   [x + 1 for x in takewhile(partial(gt,5), (0,1,2,999,3,4))]
>

No need for partial and gt.

  [x + 1 for x in takewhile((5).__gt__, (0,1,2,999,3,4))]

Basically, Haskell's infix opererator sections can often be
translated into Python by attribute access to the bound method.

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


Re: Proposed new syntax

2017-08-22 Thread Marko Rauhamaa
Paul Rubin :
> As you mention, Russell was the one who recognized the inconsistency
> in Frege's system, though I don't know how Frege took it at a personal
> level.

I read (can't remember where) that Frege was just finishing his third
and final volume when Russell's paradox was brought to his attention.
Frege was devastated, as he had spent a large part of his life on this
extensive treatise of mathematics. It turned out, though, Frege's
mistakes were fixable.

BTW, the main take of the metamathematical "fiasco" was that you can't
get rid of the meta-level. There's no consistent logical system that is
closed and encompasses everything including itself. You will always have
to step outside your formal system and resort to hand-waving in a
natural language.


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


Re: What extended ASCII character set uses 0x9D?

2017-08-22 Thread Chris Angelico
On Tue, Aug 22, 2017 at 5:15 PM, Gregory Ewing
 wrote:
> Chris Angelico wrote:
>>
>> a naive ASCII upper-casing wouldn't produce 0x81 either - if it did, it
>> would also convert 0x21 ("!") into 0x01 (SOH, a control character). So
>> this one's still a mystery.
>
>
> It's unlikely that even a naive ascii upper/lower casing algorithm
> would be *that* naive; it would have to check that the character
> appeared to be a letter before changing it.
>
> You might expect bytes >= 0x80 to be classed as non-letters by
> that test, but what if it ignores the top bit or assumes it's
> a parity bit to be left alone? What do you get under those
> assumptions?

Exactly, I do assume that it's checking for it to be a letter. But
everything previously has been on the assumption that it ignores the
top bit. That's how we got this far.

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


Re: A question on modification of a list via a function invocation

2017-08-22 Thread Gregory Ewing

Dennis Lee Bieber wrote:

On Sat, 19 Aug 2017 20:59:16 +1000, Steve D'Aprano
 declaimed the following:


I'm not sure that the VIN defines the vehicle exactly... I wouldn't want to try
driving a VIN without the rest of the vehicle. The mileage is terrible...


... or phenomenal

Depends on how one interprets 0miles / 0gallons


Your fuel consumption is NaN at that point, leading to the
well-known disclaimer in car advertisements, "Your mileage
may not be equal to itself."

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


Re: What extended ASCII character set uses 0x9D?

2017-08-22 Thread Gregory Ewing

Chris Angelico wrote:

a naive ASCII upper-casing wouldn't produce 0x81 either - if it did, it
would also convert 0x21 ("!") into 0x01 (SOH, a control character). So
this one's still a mystery.


It's unlikely that even a naive ascii upper/lower casing algorithm
would be *that* naive; it would have to check that the character
appeared to be a letter before changing it.

You might expect bytes >= 0x80 to be classed as non-letters by
that test, but what if it ignores the top bit or assumes it's
a parity bit to be left alone? What do you get under those
assumptions?

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