[issue29011] No entry Deque in typing.py

2016-12-18 Thread Raymond Hettinger

Changes by Raymond Hettinger :


--
title: No entry for deques in typing -> No entry Deque in typing.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322

2016-12-18 Thread Henning von Bargen

Henning von Bargen added the comment:

I think Eric's To-Do list sums it up pretty well.

I just wanted to say how much I appreciate the Python community. It seems that 
every little detail is very well-thought-out.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25677] Syntax error caret confused by indentation

2016-12-18 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 35b50c26f780 by Martin Panter in branch '3.5':
Issue #25677: Correct syntax error caret for indented blocks.
https://hg.python.org/cpython/rev/35b50c26f780

New changeset d4effdd699de by Martin Panter in branch '3.6':
Issue #25677: Merge SyntaxError caret positioning from 3.5
https://hg.python.org/cpython/rev/d4effdd699de

New changeset 2342726ea0c0 by Martin Panter in branch 'default':
Issue #25677: Merge SyntaxError caret positioning from 3.6
https://hg.python.org/cpython/rev/2342726ea0c0

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29011] No entry for deques in typing

2016-12-18 Thread Raymond Hettinger

Raymond Hettinger added the comment:

FWIW, I tried "d = deque() # type: typing.MutableSequence" but this gave:

error: MutableSequence[Post] has no attribute "appendleft"

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



read a table and make a basic plot

2016-12-18 Thread metal . suomi
Hi, I'm learning python and full of extensive tutorials around. Getting a bit 
lost and overflowed in my head with tuples, dictionaries, lists, etc ... etc... 
Everything great, but I'd like to perform some basic task while learning the 
rest. For example, I'm having a hard time to find some practical info to get me 
up to speed. E.g. doing the following list of tasks:

- read a file named 'data.dat' (let's suppose it has 13 columns and n lines) 
and read column 3 and 4

-plot column 3 vs column 4

-write a file 'outcome.txt' which has column 3 and 4

How do I do read and write of files? Is there some extra library I need for 
doing plots? I have read about  matplotlib.pyplot. How can I do the plot above 
using this library? (running python3.5 in OSX).

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


[issue29011] No entry for deques in typing

2016-12-18 Thread Raymond Hettinger

New submission from Raymond Hettinger:

We have:

# Concrete collection types.
'Dict',
'DefaultDict',
'List',
'Set',
'FrozenSet',
'NamedTuple',  # Not really a type.
'Generator',

But no mention of Deque.

What this an intended omission?

I would like to be able to write something like this:

   user_posts = defaultdict(deque)  # type: DefaultDict[User, Deque[Post]]

--
messages: 283590
nosy: gvanrossum, rhettinger
priority: normal
severity: normal
status: open
title: No entry for deques in typing

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29009] Outdated part in the doc of PyUnicode_RichCompare

2016-12-18 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

LGTM.

--
assignee: docs@python -> xiang.zhang
stage: patch review -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20191] resource.prlimit(int, int, str) crashs

2016-12-18 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

> Although maybe you don’t need the IndexError check in the test.

Good point. Thank you for your review Martin!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29009] Outdated part in the doc of PyUnicode_RichCompare

2016-12-18 Thread Xiang Zhang

Xiang Zhang added the comment:

> This sentence also is in the header.

Ohh, yes. Thanks Serhiy!

--
Added file: 
http://bugs.python.org/file45961/doc-of-PyUnicode_RichCompare_v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20191] resource.prlimit(int, int, str) crashs

2016-12-18 Thread Roundup Robot

Roundup Robot added the comment:

New changeset dac72bc14c00 by Serhiy Storchaka in branch '3.5':
Issue #20191: Fixed a crash in resource.prlimit() when pass a sequence that
https://hg.python.org/cpython/rev/dac72bc14c00

New changeset 7bc2923a41b6 by Serhiy Storchaka in branch '3.6':
Issue #20191: Fixed a crash in resource.prlimit() when pass a sequence that
https://hg.python.org/cpython/rev/7bc2923a41b6

New changeset b4d2bff1c5f8 by Serhiy Storchaka in branch 'default':
Issue #20191: Fixed a crash in resource.prlimit() when pass a sequence that
https://hg.python.org/cpython/rev/b4d2bff1c5f8

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29009] Outdated part in the doc of PyUnicode_RichCompare

2016-12-18 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

This sentence also is in the header.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20191] resource.prlimit(int, int, str) crashs

2016-12-18 Thread Martin Panter

Martin Panter added the comment:

Patch looks good to me. Although maybe you don’t need the IndexError check in 
the test. Won’t limit[key] already handle that for you (as long as key isn’t -1 
etc).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29007] Virus detected when attempting to download numpy-1.11.3-cp35-none-win32.whl

2016-12-18 Thread Berker Peksag

Changes by Berker Peksag :


--
assignee: christian.heimes -> 
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type: security -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29007] Virus detected when attempting to download numpy-1.11.3-cp35-none-win32.whl

2016-12-18 Thread Chi Hsuan Yen

Chi Hsuan Yen added the comment:

Sorry Crys, I misclicked on SSL and I don't have the permission to revert it :/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29007] Virus detected when attempting to download numpy-1.11.3-cp35-none-win32.whl

2016-12-18 Thread Chi Hsuan Yen

Chi Hsuan Yen added the comment:

numpy is not part of Python. Please report this to http://www.numpy.org/

--
assignee:  -> christian.heimes
components: +SSL
nosy: +Chi Hsuan Yen, christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29010] Incorrect description about scope related with inheritance

2016-12-18 Thread woo yoo

woo yoo added the comment:

The associated link is 
https://docs.python.org/3.6/tutorial/classes.html#inheritance

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files

2016-12-18 Thread Martin Panter

Martin Panter added the comment:

I finished reviewing the most recent patches and left some comments. Perhaps it 
is worth splitting the conglomerate patch up. I don’t see any point holding 
back some modules while things are tweaked in unrelated files.

My biggest concern is casting function pointers, especially when the number of 
parameters is different than expected. It would be good to fix or discuss that 
more before going ahead with floatobject.c.

--
stage: patch review -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29010] Incorrect description about scope related with inheritance

2016-12-18 Thread woo yoo

New submission from woo yoo:

The current description is "The name BaseClassName must be defined in a scope 
containing the derived class definition", which did not conform to the actual 
situation ,e.g. the base class object is not in the same scope as the derived 
class.

--
messages: 283580
nosy: woo yoo
priority: normal
severity: normal
status: open
title: Incorrect description about scope related with inheritance

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29009] Outdated part in the doc of PyUnicode_RichCompare

2016-12-18 Thread Xiang Zhang

New submission from Xiang Zhang:

The sentence:

"Note that Py_EQ and Py_NE comparisons can cause a UnicodeWarning in case the 
conversion of the arguments to Unicode fails with a UnicodeDecodeError."

in the doc of PyUnicode_RichCompare is not true in 3.x. Proposed patch simply 
deletes it.

--
assignee: docs@python
components: Documentation
files: doc-of-PyUnicode_RichCompare.patch
keywords: patch
messages: 283578
nosy: docs@python, haypo, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Outdated part in the doc of PyUnicode_RichCompare
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45960/doc-of-PyUnicode_RichCompare.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29008] Can't do dict comp from previously defined dict in the outermost scope of class defintion

2016-12-18 Thread Terry J. Reedy

Changes by Terry J. Reedy :


--
assignee: terry.reedy -> 
nosy:  -terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29008] Can't do dict comp from previously defined dict in the outermost scope of class defintion

2016-12-18 Thread Xiang Zhang

Xiang Zhang added the comment:

Also http://stackoverflow.com/a/4199355/2189957.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29008] Can't do dict comp from previously defined dict in the outermost scope of class defintion

2016-12-18 Thread Xiang Zhang

Xiang Zhang added the comment:

This is by design in 3.x. You can refer #11796 for explanation.

--
nosy: +xiang.zhang
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
superseder:  -> Comprehensions in a class definition mostly cannot access class 
variable

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29008] Can't do dict comp from previously defined dict in the outermost scope of class defintion

2016-12-18 Thread Dan Snider

New submission from Dan Snider:

class MyClass:
a_dict = {'key':'value'}
r_dict = {a_dict[k]:k for k in a_dict}

throws the error: 

Traceback (most recent call last):
  File "C:/Users/D/AppData/Local/Programs/Python/Python35-32/deleteme.py", line 
1, in 
class MyClass:
  File "C:/Users/D/AppData/Local/Programs/Python/Python35-32/deleteme.py", line 
3, in MyClass
r_dict = {a_dict[k]:k for k in a_dict}
  File "C:/Users/D/AppData/Local/Programs/Python/Python35-32/deleteme.py", line 
3, in 
r_dict = {a_dict[k]:k for k in a_dict}
NameError: name 'a_dict' is not defined

--
assignee: terry.reedy
components: IDLE, Interpreter Core, Windows
messages: 283575
nosy: Assume_Away, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Can't do dict comp from previously defined dict in the outermost scope 
of class defintion
type: behavior
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322

2016-12-18 Thread Eric Lafontaine

Eric Lafontaine added the comment:

forgot to re-post the to-do, and to correct the documentation :
List of things to do :
- Implement a patch for the code to add a missing "Date" field if it doesn't 
exist .   (in review)
- Modify the documentation at the SMTPLib for the send_message to mention that 
it add missing date using the email.utils.formatdate 
- Modify the comment of the send_message code to mention RFC 5322 in there 
(ideally with the section of the RFC).  ( in review)
- Modify the example of Python 2 to present a RFC 5322 examples 

Feedback welcome as always!

--
Added file: http://bugs.python.org/file45959/issue_28879_V3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29007] Virus detected when attempting to download numpy-1.11.3-cp35-none-win32.whl

2016-12-18 Thread Brian Davis

New submission from Brian Davis:

When attempting to download the latest numpy windows binary, it is quarantined 
due to the presence of Trojan:Win32/Spursint.A!cl.  This should be removed, and 
root caused as to how this could have made it into the package.

--
messages: 283573
nosy: Brian Davis
priority: normal
severity: normal
status: open
title: Virus detected when attempting to download  
numpy-1.11.3-cp35-none-win32.whl
type: security

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322

2016-12-18 Thread Eric Lafontaine

Eric Lafontaine added the comment:

Hi all,

this is not a short answer, like I hoped it would be ;).  But skip to the last 
section if you don't want to read it all.

the heuristic problem :

For the heuristic of the resent headers, it's clearly say in the RFC5322 that 
all resent block should be PREPENDED to messages.  So only the first ones you 
see should be handled.  email.message keeps the order of the headers while 
reading and "get" always takes the first one if it exist :).

from the RFC: 
   Each new set of resent fields is prepended to the
   message; that is, the most recent set of resent fields appears
   earlier in the message.  No other fields in the message are changed
   when resent fields are added.

For the behavior of the send_message, we used Resent-Date as it should always 
be present for EACH set of resent : 
   When resent fields are used, the "Resent-From:" and "Resent-Date:"
   fields MUST be sent.  The "Resent-Message-ID:" field SHOULD be sent.
   "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
   identical to "Resent-From:".
   
It's fantastic that things work well like this for coders :).

The issues is with the msg object being passed...  It does retain the order, 
but doesn't prepend new-headers... it only append new headers (putting them at 
the bottom of the e-mail).

If someone wants to prepend headers (i.e. the "Resend-"), they will have to 
take the msg obj and do the addition manually; 
msg._headers.insert(0,msg.policy.header_store_parse(name, val)).

They already have to do it though as the as_string function will print them at 
the bottom anyway.  Changing the "__setitem__" of message change the behavior 
too much...  even though it would be the right thing to do... email.message 
read e-mail from top to bottom and "set" each line.  In other words, for order 
dependant headers like the Resent, we're screwed.

i.e. from the test case about the multiple resent, here is what is sent down 
the "data" smtp command :
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: f...@bar.com
To: John
CC: Sally, Fred
Bcc: John Root , "Dinsdale" 
Resent-Date: Thu, 1 Jan 1970 17:42:00 +
Resent-From: h...@grail.net
Resent-To: Martha , Jeff
Resent-Bcc: d...@losthope.net
Resent-Date: Thu, 2 Jan 1970 17:42:00 +
Resent-To: h...@grail.net
Resent-From: Martha , Jeff
Date: Sun, 18 Dec 2016 20:32:11 -

A test message


___

Finally, for the "ehlo_or_helo_if_needed", I thought about it and here's what I 
think and what I believe we should be doing (I'm not attached to the idea 
though);
The send_message is a higher level of thinking and should be able to be 
modified if someone wants to act differently by sub-classing the smtplib.SMTP 
class.  in other words, if that someone wants to modify the SMTP behavior, he 
could modify the sendmail function, which would also impact the send_message 
function.

This leads the developpers to have to use ehlo and prepare the connection 
for send_message, but doesn't enforce it :).  Which would also already be the 
case of doing it with sendmail and that instead of having to over-ride 2 
methods, only one is over-written.  

If this is not desired, than I suggest "protecting our reference" by using 
thunder sendmail instead.

I prefer to remove the ehlo from the send_message and allow "flexibility" on 
the send_message itself.  
___

The issue I have right now, is what David Mentionned about the heuristic... I 
should raise an error when 2 Resent-Date are found, but that will prevent me 
from using it for production ( as I have more than one resent field present 
sometime...).  This would also prevent people from using it and I find it sad.  
For now, i'm guessing that adding a keyword parameter "guess" would be the 
right things to do, but will let that be in an other ticket.  David, I find 
that somehow the RFC5322 isn't clear enough on the "Resent-" header order, so 
I've written to the IETF to have some explanation on the rules in edge cases.  
The heuristic is implemented (takes the first one it finds), but just not 
activated yet for multiple Resent-Date.

I'll re-iterate my need for someone to review the code though :).

Eric Lafontaine

--
Added file: http://bugs.python.org/file45958/issue_28879_V2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: python list index - an easy question

2016-12-18 Thread Ben Bacarisse
BartC  writes:

> On 18/12/2016 10:59, Paul Götze wrote:
>> there is a nice short article by E. W. Dijkstra about why it makes sense
>> to start numbering at zero (and exclude the upper given bound) while
>> slicing a list. Might give a bit of additional understanding.
>>
>> http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
>
> (This from somebody who apparently can't use a typewriter?!)
>
> I don't know if the arguments there are that convincing. Both lower
> bounds of 0 and 1 are useful; some languages will use 0, some 1, and
> some can have any lower bound.
>
> But a strong argument for using 1 is that in real life things are
> usually counted from 1 (and measured from 0).

The index of an element is a measure, not a count.


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


[issue28927] bytes.fromhex should ignore all whitespace

2016-12-18 Thread Nick Coghlan

Nick Coghlan added the comment:

+1 to the above Unicode whitespace discussion - the "ASCII space -> ASCII 
whitespace" change is relatively straightforward to implement, and clearly 
beneficial given Robert's point regarding the popularity of multi-line 
terminal-oriented hexdump formats.

Neither of those points apply to Unicode whitespace (it would be much harder to 
implement, and we don't have a demonstrated use case for it), so it makes sense 
to avoid going that far.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: The right way to 'call' a class attribute inside the same class

2016-12-18 Thread Chris Angelico
On Mon, Dec 19, 2016 at 9:52 AM, Erik  wrote:
>
> 1) Method call:
>"obj.foo(1, 2, 3)" is syntactic sugar for "obj.foo(obj, 1, 2, 3)".

And the bit you have to be REALLY careful of when working with both
Python and JS is that you have to have "obj.foo(...)" as a single
expression. Consider:

# Python
lst = []
func = lst.append
func(1); func(2); func(3)
# lst now holds [1,2,3]

// JavaScript
var arr = []
var func = arr.push.bind(arr) // IMPORTANT
func(1); func(2); func(3)
// arr now contains [1,2,3]

If you just take "arr.push", you don't get a bound method. You get an
unbound method. You have to explicitly bind that back to the array
object, or its "this" pointer won't be set.

This is so important (eg with callback functions) that JS introduced a
new type of function to help deal with the problem...

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


Re: The right way to 'call' a class attribute inside the same class

2016-12-18 Thread Erik


NOTE: If you found this message by searching for help on how Python 
works, be aware that it's discussing how JavaScript works, not Python! 
Look elsewhere :)


Chris, this isn't directed at you (I think you get it) - just following 
up with some detail for anyone who might discover this sub-thread when 
searching in future.


On 18/12/16 01:21, Chris Angelico wrote:

On Sun, Dec 18, 2016 at 12:01 PM, Erik  wrote:

I wish I could find the resource I originally learned this stuff from,
because it's quite enlightening and I'd like to link to it here



Sounds like how Michael Schwern introduces his "Git for Ages 4 and Up"
talk


Just in case anyone is remotely interested, I've found a reasonable link 
(but it's not the one I was looking for).


I realise this is off-topic for a Python list, but it has come up 
because of a Python question so I thought why not ... (I wish someone 
had explained this to me in roughly-Python terms when I first had to 
deal with JS ;)).


In short, AIUI, all JS functions have an implicit initial parameter 
which is named 'this'. What that parameter is bound to depends on the 
context of the call to that function object. In Python the callable is 
of a particular type (method, function, generator) but on JS (for the 
purposes of this discussion (pun intended ;)) they are all equal and 
it's the calling context that determines what happens.


A JS function, whether declared with "function Foo(a, b, c) {}" or as an 
expression "function (a, b, c) {}" has an implicit initial parameter 
which is bound to the variable 'this' (so they are really "function 
Foo(this, a, b, c) {}", "function (this, a, b, c) {}").


The value of that initial first parameter is determined by how they are 
called. There are three main ways:


1) Method call:
   "obj.foo(1, 2, 3)" is syntactic sugar for "obj.foo(obj, 1, 2, 3)".

2) Function call:
   "foo(1, 2, 3)" is syntactic sugar for "foo(GLOBAL_OBJECT, 1, 2, 3)" 
where "GLOBAL_OBJECT" is whatever the execution environment defines as 
being the global object. In a browser, I think it's "window", in the JS 
strict mode, I think it's "undefined" (i.e., no object), in Node.js I 
think it might be something else entirely.


3) Constructor call:
   "new foo(1, 2, 3)" is syntactic sugar for "foo(NEWOBJ, 1, 2, 3)" 
where NEWOBJ is a newly allocated, empty object.


The other way of invoking a function object is via its "call" method 
where the initial 'this' parameter can be explicitly given - 
"foo.call(SPAM, 1, 2, 3)" - which is how to implement bound methods and 
that sort of thing.



The main area of confusion seems to be when passing function expressions 
(closures) as a callback to another function:


function Foo() {
  ham(this.a, this.b, function (x) { this.frobnicate(x); });
}

Let's assume this is called with "obj.Foo();". In the function itself, 
'this', is bound to 'obj'. However, in the body of the (anonymous) 
function expression/closure (which sort of looks to be at the same scope 
as everything else) 'this' is bound according to the rules above being 
applied to at the point it is called - the object it is bound to almost 
certainly doesn't have the "frobnicate" method expected.


This is why the following works:

function Foo() {
  _this = this;
  ham(this.a, this.b, function (x) { _this.frobnicate(x); });
}

The closure now knows how to address the 'this' object for the original 
method even though it is called later by whatever 'ham()' does. Using a 
bound function as the callback works in the same way.




Anyway, off-topic as I said, but if it helps other Pythoneers get to 
grips with some of the weird JS semantics, it's all good :)




The link I *did* find (which probably has a bit more depth) is:

https://rainsoft.io/gentle-explanation-of-this-in-javascript/


Cheers, E.
--
https://mail.python.org/mailman/listinfo/python-list


Re: python list index - an easy question

2016-12-18 Thread BartC

On 18/12/2016 22:21, BartC wrote:

On 18/12/2016 21:04, Michael Torrie wrote:

On 12/18/2016 09:21 AM, BartC wrote:



So if you wanted a simple list giving the titles of the chapters in a
book or on a DVD, on the colour of the front doors for each house in a
street, usually you wouldn't be able to use element 0.


It also depends on whether you want to number the spaces between the
objects or the objects themselves. To use your DVD example, the first
chapter will probably be starting at time zero, not time one.

In another example, babies start out at "zero" years old not "one."  But
at the same time we refer the first year of life.  Maybe it's not a
phrase much used these days but it used to be common to say something
like "in my 15th year," meaning when I was 14.  Maybe a more common use
would be "the first year of my employment at this company."


There's the fence analogy (perhaps similar to what alister said):

You have a fence made up of one-metre-wide panels that fit between two
posts.

For a 10-metre fence, you need 11 posts, and 10 panels.

The posts can conveniently be numbered from 0 to 11,


... 0 to 10.

That's the thing with zero-based; it might reduce some off-by-one errors 
but could introduce others.


With the panels you have 10 panels numbered 1 to 10; what could be 
simpler or more intuitive?


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


Re: python list index - an easy question

2016-12-18 Thread BartC

On 18/12/2016 21:04, Michael Torrie wrote:

On 12/18/2016 09:21 AM, BartC wrote:



So if you wanted a simple list giving the titles of the chapters in a
book or on a DVD, on the colour of the front doors for each house in a
street, usually you wouldn't be able to use element 0.


It also depends on whether you want to number the spaces between the
objects or the objects themselves. To use your DVD example, the first
chapter will probably be starting at time zero, not time one.

In another example, babies start out at "zero" years old not "one."  But
at the same time we refer the first year of life.  Maybe it's not a
phrase much used these days but it used to be common to say something
like "in my 15th year," meaning when I was 14.  Maybe a more common use
would be "the first year of my employment at this company."


There's the fence analogy (perhaps similar to what alister said):

You have a fence made up of one-metre-wide panels that fit between two 
posts.


For a 10-metre fence, you need 11 posts, and 10 panels.

The posts can conveniently be numbered from 0 to 11, as that also gives 
you the distance of each one from the start of the fence.


But posts are thin. Panels are wide, and they might as well be 
conventionally numbered from 1, as you can't use the panel number to 
tell you how far it is from the start (is it the left bit of the panel 
or the right bit?).


Panels obviously correspond to the data in each list element; posts are 
harder to place, except perhaps as alister's commas (but then there have 
to be extra invisible commas at each end).


(The fence needs to divide an open area not surround an enclosed space, 
as otherwise the analogy breaks down; you will have N panels and N posts!)



I'm not sure it makes sense to having slicing be zero-based but indexing
itself be 1-based, but I think a case could have been made (though I'm
glad it was not).


They need to be the same.

(Zero-based necessarily has to be used with offsets from pointers from 
example. In C, array indexing is inextricably tied up with 
pointer/offset arithmetic, so indexing /has/ to be zero-based.


But that doesn't apply in other languages where the choice could have 
been different.)


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


Re: python list index - an easy question

2016-12-18 Thread Cameron Simpson

On 18Dec2016 16:21, BartC  wrote:

On 18/12/2016 10:59, Paul Götze wrote:

there is a nice short article by E. W. Dijkstra about why it makes sense
to start numbering at zero (and exclude the upper given bound) while
slicing a list. Might give a bit of additional understanding.

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF


(This from somebody who apparently can't use a typewriter?!)

I don't know if the arguments there are that convincing. Both lower 
bounds of 0 and 1 are useful; some languages will use 0, some 1, and 
some can have any lower bound.


0 makes a lot of arithmetic simpler if you think of the index as the offset 
from the start of the array/list.


But a strong argument for using 1 is that in real life things are 
usually counted from 1 (and measured from 0).


Shrug. Yep. But again, if you visualise the index as an offset (== "measure") 
it is a natural fit.


Another little anomaly in Python is that when negative indices are used, it 
suddenly switches to 1-based indexing! Or least, when -index is considered:


Not if you consider it to count from the range end. So range 0:5 (which in 
Python includes indices 0,1,2,3,4); index -1 places you at 5-1 ==> 4, which is 
consistent. Again, this makes a lot of the arithmetic simpler.


See sig quote for another example of a python style range: birth to death.

Cheers,
--
Cameron Simpson 

There's no need to worry about death, it will not happen in your lifetime.
   - Raymond Smullyan
--
https://mail.python.org/mailman/listinfo/python-list


[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

2016-12-18 Thread Armin Rigo

Armin Rigo added the comment:

Or maybe it would be enough to change commit() so that if Sqlite fails with 
"table is locked", pysqlite would reset all cursors and then try again?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: Best attack order for groups of numbers trying to destroy each other, given a victory chance for number to number attack.

2016-12-18 Thread skybuck2000
Dennis wrote:



"
Instead you /now/ have ONE set of R marching down FOUR sets of B

RT  RD  RF  RP  <-  
attackers
BT  BF  BF  BP  
round 1
BF  BD  BP  BF  
round 2
BD  BP  BD  BD  
round 3
BP  BT  BT  BT  
round 4 
"

Yes this is how the problem works.

Also keep in mind that an attack is only valid if the target is still alive, 
otherwise the attacker would move to the next one.

So pre-computing an attack plan/outcome or storing it might not be so usefull 
for on color, since the other color might already be dead and thus attack plan 
was calculated incorrectly potentially.

So it's quite a difficult/complex/dynamic problem !
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: OT - "Soft" ESC key on the new MacBook Pro

2016-12-18 Thread Gregory Ewing

mm0fmf wrote:

+1 for knowing where CTRL should be.
Bonus +1 for having used an ASR33.


And it's quite remarkable that the designers of the ASR33
knew exactly where it would need to be for Emacs users
years later! I think Richard Stallman must have a time
machine as well.

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


Re: OT - "Soft" ESC key on the new MacBook Pro

2016-12-18 Thread Skip Montanaro
> +1 for knowing where CTRL should be.
Bonus +1 for having used an ASR33.

;-)


I'm sure I must have used an ASR33, but can't recall what it might have
been connected to. I do remember using card punch machines for IBM 360
input in 1972 at USC, and toggling front panel switches for binary input on
a PDP-11 in one engineering class in grad school at Iowa. Hand assembling
your program isn't terrific fun.

With this polar vortex going on, I'm not sure when I'll have the cojones to
brave the weather for an otherwise unnecessary trip to the Apple Store.

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


Re: OT - "Soft" ESC key on the new MacBook Pro

2016-12-18 Thread mm0fmf

On 15/12/2016 18:05, Peter Pearson wrote:

On Wed, 14 Dec 2016 11:50:30 -0600, Skip Montanaro wrote:

On Wed, Dec 14, 2016 at 11:40 AM, Peter Pearson
 wrote:

Train your fingers to use C-[.


As I recall, the location of the Ctrl key was one of the differences
between Sun and PC101 keyboards. Doesn't matter so much now, as Sun
has gone the way of the dodo, but it moved around more for me than ESC
over the years.


Absolutely right.  Random migrations of the Ctrl key annoyed so many
of us set-in-our-ways geezers that Linux distributions always seem to
come with an easily activated option to put the Ctrl key where it
belongs, namely to the left of the A, right where God put it on Adam's
ASR 33.


+1 for knowing where CTRL should be.
Bonus +1 for having used an ASR33.

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


[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

2016-12-18 Thread Ned Deily

Changes by Ned Deily :


--
nosy: +benjamin.peterson, berker.peksag, ghaering

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

2016-12-18 Thread Armin Rigo

New submission from Armin Rigo:

2.7.13 did a small change to the sqlite commit() method, 
http://bugs.python.org/issue10513, which I think is causing troubles.  I 
noticed the problem in PyPy, which (with the same change) fails another test in 
Lib/sqlite3/test/regression.py, CheckTypeMapUsage(), containing this code:

...
con.execute(SELECT)
con.execute("drop table foo")
...

The first execute() method creates a cursor; assuming it is not promptly 
deleted, its mere existence causes the second execute() method to fail inside 
Sqlite with "OperationalError: database table is locked".  As a second step, I 
could reproduce the problem in CPython by changing the test like this:

...
keepalive = con.execute(SELECT)# the cursor stays alive
con.execute("drop table foo")
...

The reason is that in the commit() done by the second execute(), we no longer 
reset all this connection's cursors before proceeding.  But depending on the 
operation, Sqlite may then complain that the "table is locked" by these old 
cursors.  In other words, this new situation introduced in 2.7.13 potentially 
makes a few complicated cases crash by "table is locked" on CPython, where they 
would work fine previously---which is bad IMHO.  About PyPy, many more cases 
would crash, to the point that we may have no choice but not implement this 
2.7.13 change at all.

--
messages: 283569
nosy: arigo
priority: normal
severity: normal
status: open
title: 2.7.13 _sqlite more prone to "database table is locked"
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: python list index - an easy question

2016-12-18 Thread Michael Torrie
On 12/18/2016 09:21 AM, BartC wrote:
> On 18/12/2016 10:59, Paul Götze wrote:
>> Hi John,
>>
>> there is a nice short article by E. W. Dijkstra about why it makes sense
>> to start numbering at zero (and exclude the upper given bound) while
>> slicing a list. Might give a bit of additional understanding.
>>
>> http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
> 
> (This from somebody who apparently can't use a typewriter?!)
> 
> I don't know if the arguments there are that convincing. Both lower 
> bounds of 0 and 1 are useful; some languages will use 0, some 1, and 
> some can have any lower bound.
> 
> But a strong argument for using 1 is that in real life things are 
> usually counted from 1 (and measured from 0).
> 
> So if you wanted a simple list giving the titles of the chapters in a 
> book or on a DVD, on the colour of the front doors for each house in a 
> street, usually you wouldn't be able to use element 0.

It also depends on whether you want to number the spaces between the
objects or the objects themselves. To use your DVD example, the first
chapter will probably be starting at time zero, not time one.

In another example, babies start out at "zero" years old not "one."  But
at the same time we refer the first year of life.  Maybe it's not a
phrase much used these days but it used to be common to say something
like "in my 15th year," meaning when I was 14.  Maybe a more common use
would be "the first year of my employment at this company."

I'm not sure it makes sense to having slicing be zero-based but indexing
itself be 1-based, but I think a case could have been made (though I'm
glad it was not).
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: python list index - an easy question

2016-12-18 Thread alister
On Sun, 18 Dec 2016 16:21:20 +, BartC wrote:

> On 18/12/2016 10:59, Paul Götze wrote:
>> Hi John,
>>
>> there is a nice short article by E. W. Dijkstra about why it makes
>> sense to start numbering at zero (and exclude the upper given bound)
>> while slicing a list. Might give a bit of additional understanding.
>>
>> http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
> 
> (This from somebody who apparently can't use a typewriter?!)
> 
> I don't know if the arguments there are that convincing. Both lower
> bounds of 0 and 1 are useful; some languages will use 0, some 1, and
> some can have any lower bound.
> 
> But a strong argument for using 1 is that in real life things are
> usually counted from 1 (and measured from 0).
> 
> So if you wanted a simple list giving the titles of the chapters in a
> book or on a DVD, on the colour of the front doors for each house in a
> street, usually you wouldn't be able to use element 0.
> 
> As for slice notation, I tend to informally use (not for any particulr
> language) A..B for an inclusive range, and A:N for a range of length N
> starting from A.
> 
> In Python you can also have a third operand for a range, A:B:C, which
> can mean that B is not necessarily one past the last in the range, and
> that the A <= i < B condition in that paper is no longer quite true.
> 
> In fact, A:B:-1 corresponds to A >= i > B, which I think is the same as
> condition (b) in the paper (but backwards), rather (a) which is
> favoured.
> 
> Another little anomaly in Python is that when negative indices are used,
> it suddenly switches to 1-based indexing! Or least, when -index is
> considered:
> 
>x = [-4,-3,-2,-1]
> 
>print x[-1]   # -1  Notice the correspondence here...
>print x[-2]   # -2
> 
>x = [1, 2, 3, 4]
> 
>print x[1]# 2   ...and the lack of it here print x[2]   
># 3


as I said earlier
take the indicates as being the spaces between the elements & it makes 
much more sense


-- 
falsie salesman, n:
Fuller bust man.
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue9253] argparse: optional subparsers

2016-12-18 Thread Hans-Peter Jansen

Changes by Hans-Peter Jansen :


--
nosy: +frispete

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29005] Possibly incorrect description about method objects

2016-12-18 Thread R. David Murray

R. David Murray added the comment:

Thanks, woo and Jim.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29005] Possibly incorrect description about method objects

2016-12-18 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 6f89f5eb4422 by R David Murray in branch '3.5':
#29005: clarify terminology in tutorial 'method' discussion.
https://hg.python.org/cpython/rev/6f89f5eb4422

New changeset 7314e08dc907 by R David Murray in branch '3.6':
Merge: #29005: clarify terminology in tutorial 'method' discussion.
https://hg.python.org/cpython/rev/7314e08dc907

New changeset 3cc193be79ab by R David Murray in branch 'default':
Merge: #29005: clarify terminology in tutorial 'method' discussion.
https://hg.python.org/cpython/rev/3cc193be79ab

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29005] Possibly incorrect description about method objects

2016-12-18 Thread Jim Fasarakis-Hilliard

Jim Fasarakis-Hilliard added the comment:

Agreed, attached amended patch

--
Added file: http://bugs.python.org/file45957/method_obj35_2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29005] Possibly incorrect description about method objects

2016-12-18 Thread R. David Murray

R. David Murray added the comment:

I think it is better to say "the method's instance object", because in the 
final paragraph we discuss the fact that each method object has an associated 
instance object.  The instance object isn't magically acquired from elsewhere 
and added, it is added because it has been bound into the method object.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28997] test_readline.test_nonascii fails on Android

2016-12-18 Thread Xavier de Gaye

Xavier de Gaye added the comment:

Checking that the the problem is indeed an encoding problem on Android with 
readline.set_pre_input_hook(): with tracing_the_completer_2.patch that replaces 
'\xEB' with 'A', the test now succeeds and prints:

test_nonascii (test.test_readline.TestReadline) ... 
bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n[\\303\\257nserted]|tA[after]\x08\x08\x08\x08\x08\x08\x08text
 \'tA\'\r\nline \'[\\xefnserted]|tA[after]\'\r\nindexes 11 13\r\n\x07text 
\'tA\'\r\nline \'[\\xefnserted]|tA[after]\'\r\nindexes 11 13\r\nsubstitution 
\'tA\'\r\nmatches [\'tAnt\', 
\'tAxt\']\r\nx[after]\x08\x08\x08\x08\x08\x08\x08t[after]\x08\x08\x08\x08\x08\x08\x08\r\nresult
 \'[\\xefnserted]|tAxt[after]\'\r\nhistory 
\'[\\xefnserted]|tAxt[after]\'\r\ncompleter [\'tA-0\', \'GOT 1\', \'tA-1\', 
\'GOT 2\', \'tA-2\', \'tA-0\', \'GOT 1\', \'tA-1\', \'GOT 2\', \'tA-2\', 
\'tAx-0\', \'GOT 3\', \'tAx-1\']\r\n")
ok

--
Added file: http://bugs.python.org/file45956/tracing_the_completer_2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28997] test_readline.test_nonascii fails on Android

2016-12-18 Thread Xavier de Gaye

Xavier de Gaye added the comment:

FWIW on Android we have:

>>> readline.__doc__ and "libedit" in readline.__doc__
False
>>> getattr(readline, "set_pre_input_hook", None)


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29005] Possibly incorrect description about method objects

2016-12-18 Thread Jim Fasarakis-Hilliard

Jim Fasarakis-Hilliard added the comment:

I've added a little patch that takes care of this. I didn't add "method's 
instance object" in the second substitution because it seems evident by the 
previous sentences.

--
keywords: +patch
Added file: http://bugs.python.org/file45955/method_obj35.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

2016-12-18 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

(S3) is a side effect of implementing __eq__ in dict_keys and dict_items. Since 
__eq__ is not implemented in dict_values, __hash__ is inherited from object.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: python list index - an easy question

2016-12-18 Thread BartC

On 18/12/2016 10:59, Paul Götze wrote:

Hi John,

there is a nice short article by E. W. Dijkstra about why it makes sense
to start numbering at zero (and exclude the upper given bound) while
slicing a list. Might give a bit of additional understanding.

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF


(This from somebody who apparently can't use a typewriter?!)

I don't know if the arguments there are that convincing. Both lower 
bounds of 0 and 1 are useful; some languages will use 0, some 1, and 
some can have any lower bound.


But a strong argument for using 1 is that in real life things are 
usually counted from 1 (and measured from 0).


So if you wanted a simple list giving the titles of the chapters in a 
book or on a DVD, on the colour of the front doors for each house in a 
street, usually you wouldn't be able to use element 0.


As for slice notation, I tend to informally use (not for any particulr 
language) A..B for an inclusive range, and A:N for a range of length N 
starting from A.


In Python you can also have a third operand for a range, A:B:C, which 
can mean that B is not necessarily one past the last in the range, and 
that the A <= i < B condition in that paper is no longer quite true.


In fact, A:B:-1 corresponds to A >= i > B, which I think is the same as 
condition (b) in the paper (but backwards), rather (a) which is favoured.


Another little anomaly in Python is that when negative indices are used, 
it suddenly switches to 1-based indexing! Or least, when -index is 
considered:


  x = [-4,-3,-2,-1]

  print x[-1]   # -1  Notice the correspondence here...
  print x[-2]   # -2

  x = [1, 2, 3, 4]

  print x[1]# 2   ...and the lack of it here
  print x[2]# 3


--
Bartc

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


[issue29005] Possibly incorrect description about method objects

2016-12-18 Thread R. David Murray

R. David Murray added the comment:

Given the (clearer) explanation in the final paragraph of that section, I think 
the bare 'object' in the first couple paragraphs should be replaced by 
'instance object'.  There are multiple objects involved, and that will 
disambiguate which one is being referred to for insertion as the first 
argument, and make the language of the section self-consistent.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29005] Possibly incorrect description about method objects

2016-12-18 Thread Jim Fasarakis-Hilliard

Jim Fasarakis-Hilliard added the comment:

I see. I'd agree that `instance object` is probably better here. Let's see what 
others think.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29005] Possibly incorrect description about method objects

2016-12-18 Thread woo yoo

woo yoo added the comment:

Maybe the last "method's" should be changed into "class instance"

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29005] Possibly incorrect description about method objects

2016-12-18 Thread Jim Fasarakis-Hilliard

Jim Fasarakis-Hilliard added the comment:

Seems right to me, this is also stated clearly in the reference manual:

> When an instance method object is called, the underlying function (__func__) 
> is called, inserting the class instance (__self__) in front of the argument 
> list. For instance, when C is a class which contains a definition for a 
> function f(), and x is an instance of C, calling x.f(1) is equivalent to 
> calling C.f(x, 1).

What doesn't look right to you?

--
nosy: +Jim Fasarakis-Hilliard

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29005] Possibly incorrect description about method objects

2016-12-18 Thread woo yoo

New submission from woo yoo:

"In general, calling a method with a list of n arguments is equivalent to 
calling the corresponding function with an argument list that is created by 
inserting the method’s object before the first argument."

Is  above description right?
The link is https://docs.python.org/3.5/tutorial/classes.html#method-objects

--
assignee: docs@python
components: Documentation
messages: 283556
nosy: docs@python, woo yoo
priority: normal
severity: normal
status: open
title: Possibly incorrect description about method objects
versions: Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28997] test_readline.test_nonascii fails on Android

2016-12-18 Thread Xavier de Gaye

Xavier de Gaye added the comment:

> For me, it prints this: (includes “te” with an umlaut)
I got this same result when testing on Android with the interactive interpreter.

See the content of the 'completer' list below, when run with 
tracing_the_completer.patch:
On linux:
test_nonascii (test.test_readline.TestReadline) ... 
bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n[\xc3\xafnserted]|t\xc3\xab[after]\x08\x08\x08\x08\x08\x08\x08text
 \'t\\xeb\'\r\nline \'[\\xefnserted]|t\\xeb[after]\'\r\nindexes 11 13\r\ntext 
\'t\\xeb\'\r\nline \'[\\xefnserted]|t\\xeb[after]\'\r\nindexes 
1113\r\nsubstitution \'t\\xeb\'\r\nmatches [\'t\\xebnt\', 
\'t\\xebxt\']\r\nx[after]\x08\x08\x08\x08\x08\x08\x08t[after]\x08\x08\x08\x08\x08\x08\x08\r\nresult
 \'[\\xefnserted]|t\\xebxt[after]\'\r\nhistory 
\'[\\xefnserted]|t\\xebxt[after]\'\r\ncompleter [\'t\xc3\xab-0\', \'GOT 1\', 
\'t\xc3\xab-1\', \'GOT 2\', \'t\xc3\xab-2\', \'t\xc3\xab-0\', \'GOT 1\', 
\'t\xc3\xab-1\', \'GOT 2\', \'t\xc3\xab-2\', \'t\xc3\xabx-0\', \'GOT 3\', 
\'t\xc3\xabx-1\']\r\n")

On Android:
AssertionError: b"text 't\\xeb'\r\n" not found in 
bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n[\\303\\257nserted]|t\x07\x08\x08\x08\x08\x08\x08\x08\x07\x07xrted]|t\x08\x08\x08\x08\x08\x08\x08\x07\r\nresult
 \'[\\xefnsexrted]|t\'\r\nhistory \'[\\xefnsexrted]|t\'\r\ncompleter 
[\'\xc3\xafnse-0\', \'\xc3\xafnse-0\', \'\xc3\xafnsex-0\']\r\n")

b'\xc3\xab' is the UTF-8 code for '\xEB'
b'\xc3\xaf' is the UTF-8 code for '\xEF'
It seems that the completer is triggered by the wrong key.

--
keywords: +patch
Added file: http://bugs.python.org/file45954/tracing_the_completer.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[Release] Pyo 0.8.2 (Python dsp library)

2016-12-18 Thread Olivier Bélanger
Hello all,

I'm glad to announce the release of pyo 0.8.2, available for python 2.7 and 3.5.

Pyo is a Python module written in C to help real-time digital signal processing
script creation. It is available for Windows, macOS and linux. It is released
under the LGPL 3 license.

For more info, downloads and other links, see the official web site:

http://ajaxsoundstudio.com/software/pyo/

The documentation:

http://ajaxsoundstudio.com/pyodoc/

For the latest sources and bug tracker:

https://github.com/belangeo/pyo

What's new:
- Fixed latency issue when using portaudio as audio backend.
- TrigFunc and Pattern now accept a tuple as "arg" argument (fixed issue #90).
- E-Pyo: Fixed a bug in the documentation window.
- Fixed midi input events handling.
- Set interpolation to off by default for midi continuous controllers.

Olivier Belanger
belan...@gmail.com
http://olivier.ajaxsoundstudio.com/



P>http://ajaxsoundstudio.com/software/pyo/;>Pyo 0.8.1
Python DSP library. (17-Dec-16)
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/


Re: python list index - an easy question

2016-12-18 Thread Paul Götze
Hi John,

there is a nice short article by E. W. Dijkstra about why it makes sense
to start numbering at zero (and exclude the upper given bound) while
slicing a list. Might give a bit of additional understanding.

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

- paul


http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF


Am 17.12.2016 um 20:10 schrieb John:
> Hi, 
>
>I am new to Python, and I believe it's an easy question. I know R and 
> Matlab.
>
> 
 x=[1,2,3,4,5,6,7]
 x[0]
> 1
 x[1:5]
> [2, 3, 4, 5]
> *
>
> My question is: what does x[1:5] mean? By Python's convention, the first 
> element of a list is indexed as "0". Doesn't x[1:5] mean a sub-list of x, 
> indexed 1,2,3,4,5? If I am right, it should print [2,3,4,5,6]. Why does it 
> print only [2,3,4,5]?
>
>Thanks!!
>
> John


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


[RELEASE] Python 2.7.13

2016-12-18 Thread Benjamin Peterson
It is my pleasure to announce the release of Python 2.7.13, the latest
bugfix release of the venerable Python 2.7 series. This release
incorporates conservative bugfixes as well as improvements to keep
Python 2.7 running on modern systems.

The only change from the 2.7.13 release candidate 2 weeks ago is the
revert of a change that broke backwards compatibility with some rare C
extension patterns. See https://bugs.python.org/issue5322 for more
details.

Source archives and binaries are available at
https://www.python.org/downloads/release/python-2713/

Please report bugs to our tracker:
https://bugs.python.org/

2.7.14 will appear mid-2017.

All the best in the new year,
Benjamin Peterson
2.7 release manager
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/


Re: print() with no newline

2016-12-18 Thread ElChino
Chris Warrick wrote:

>> I'm getting a syntax error in Python2. Python3 is fine.
>> How can I make this Py2+3 compatible?
> 
> With a __future__ import, the Python 3 syntax will work with both Pythons:
> 
> from __future__ import print_function
> print(s, end="")

Thanks. Lovely.


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


[issue23507] Tuple creation is too slow

2016-12-18 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Here is rebased patch (just for history). Caching argtuple is not faster (or 
even slower) than using fast call.

Regression in stack consumption is fixed in issue28858.

Thanks Victor!

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
Added file: http://bugs.python.org/file45953/reuse_argtuples_4.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: print() with no newline

2016-12-18 Thread Chris Warrick
On 18 December 2016 at 13:25, ElChino  wrote:
> In this snippet:
>   import sys
>   PY3 = (sys.version_info[0] >= 3)
>
>   def print_no_nl (s):
> if PY3:
>   print (s, end="")
> else:
>   print (s),
>
> I'm getting a syntax error in Python2. Python3 is fine.
> How can I make this Py2+3 compatible?

With a __future__ import, the Python 3 syntax will work with both Pythons:

from __future__ import print_function
print(s, end="")

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list


print() with no newline

2016-12-18 Thread ElChino
In this snippet:
  import sys
  PY3 = (sys.version_info[0] >= 3)

  def print_no_nl (s):
if PY3:
  print (s, end="")
else:
  print (s),

I'm getting a syntax error in Python2. Python3 is fine.
How can I make this Py2+3 compatible?
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue29004] binascii.crc_hqx() implements CRC-CCITT

2016-12-18 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Okay, then the patch LGTM. Use the form of the polynomial that you prefer.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29004] binascii.crc_hqx() implements CRC-CCITT

2016-12-18 Thread Martin Panter

Martin Panter added the comment:

It seems I can write it without the escaped spaces. Is there a problem with 
this:

*x*:sup:`16` + *x*:sup:`12` + *x*:sup:`5` + 1

I’m happy to add the CRC-32 polynomial if you think it would be useful, 
although it is a lot longer (fifteen terms instead of four). And this CRC is 
already easily identified by the CRC-32 name. As well as the polynomial, there 
are other details that identify a CRC. The bits in CRC-32 are reversed and 
inverted compared to CRC-CCITT.

>>> hex(crc32(b"\x80", 0x) ^ 0x)
'0xedb88320'
# 0xEDB88320 is the reversed polynomial representation; the x^0 term 
corresponds to bit 31

Adler32 is not a CRC, and I don’t think there are multiple versions of the 
algorithm, so I don’t think it would need any special explanation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28927] bytes.fromhex should ignore all whitespace

2016-12-18 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

No, it is not easy to implement. Currently bytes.fromhex() works only with 
ASCII strings and can just iterate over char*.

If add support of non-ASCII whitespaces, we should add a support of non-ASCII 
digits, as in float(). This looks excessive.

In case if there is a case for this, we rather would expose 
_PyUnicode_TransformDecimalAndSpaceToASCII() in Python level.

In general fromhex.patch LGTM, but please add versionchanged directives and 
document the change in What's New.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29004] binascii.crc_hqx() implements CRC-CCITT

2016-12-18 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

If document the polynomial for crc_hqx, maybe document it for crc32 and adler32?

Wouldn't be better to write the formula as *x*\ :sup:`16` + *x*\ :sup:`12 + 
*x*\ :sup:`5` + 1 ?

--
nosy: +eric.smith, lemburg, mark.dickinson, serhiy.storchaka, stutzbach

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28927] bytes.fromhex should ignore all whitespace

2016-12-18 Thread Martin Panter

Martin Panter added the comment:

As far as I know, non-ASCII newlines and whitespace are not supported in Python 
source code, so there is not a big need to support it in bytes.fromhex() 
either. But since bytes.fromhex() accepts Unicode strings, I think non-ASCII 
whitespace would be okay if it was easy to implement.

Serhiy: Whitespace is not treated specially by the base-64 decoders, it is just 
treated like any non-alphabet character. See 
 and 
b64decode(validate=True).

Regarding hex-codec, I doubt many people use it in Python 3. To decode a whole 
string, binascii.unhexlify() or bytes.fromhex() is probably more obvious, and I 
think the incremental decoder never worked properly (Issue 20132).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29004] binascii.crc_hqx() implements CRC-CCITT

2016-12-18 Thread Martin Panter

New submission from Martin Panter:

If I had known this it would have saved me getting a separate implementation 
working.

>>> hex(binascii.crc_hqx(b"\x01", 0))
'0x1021'
https://files.stairways.com/other/binhex-40-specs-info.txt

Documenting this might helped many other people. Top Google hits seem oblivious 
to crc_hqx(), using other CRC implementations, and even other helper functions 
from the binascii module:

https://pypi.python.org/pypi/crc16
http://stackoverflow.com/questions/26204060/calculate-crc-ccitt-0x-for-hex-string

--
assignee: docs@python
components: Documentation
files: crc-ccitt.patch
keywords: patch
messages: 283548
nosy: docs@python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: binascii.crc_hqx() implements CRC-CCITT
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45952/crc-ccitt.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *"

2016-12-18 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Opened a topic on Python-Dev: 
https://mail.python.org/pipermail/python-dev/2016-December/147029.html.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28932] Fail compile Python 3.6.0rc1 on OpenBSD 6.0

2016-12-18 Thread Serhiy Storchaka

Changes by Serhiy Storchaka :


--
nosy: +benjamin.peterson, ned.deily
priority: normal -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28932] Fail compile Python 3.6.0rc1 on OpenBSD 6.0

2016-12-18 Thread Remi Pointel

Remi Pointel added the comment:

Hello,

I have exactly the same problem with Python 2.7.13 on OpenBSD.

Works fine with the same patch.

Remi.

--
nosy: +rpointel
versions: +Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28927] bytes.fromhex should ignore all whitespace

2016-12-18 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Is it worth to ignore also non-ASCII whitespaces for compatibility with 
string-to-number convertions and base64 decoder?

>>> float('\xa01.0')
1.0
>>> base64.decodebytes(b'\xa0YWJj')
b'abc'

Note that not all spaces are ignored. They shouldn't break hexadecimal pairs.

>>> bytes.fromhex('a b')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: non-hexadecimal number found in fromhex() arg at position 1

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Re: python list index - an easy question

2016-12-18 Thread alister
On Sat, 17 Dec 2016 11:10:22 -0800, John wrote:

> Hi,
> 
>I am new to Python, and I believe it's an easy question. I know R and
>Matlab.
> 
> 
 x=[1,2,3,4,5,6,7]
 x[0]
> 1
 x[1:5]
> [2, 3, 4, 5] *
> 
> My question is: what does x[1:5] mean? By Python's convention, the
> first element of a list is indexed as "0". Doesn't x[1:5] mean a
> sub-list of x, indexed 1,2,3,4,5? If I am right, it should print
> [2,3,4,5,6]. Why does it print only [2,3,4,5]?
> 
>Thanks!!
> 
> John

as well as al the other excellent & detailed explanations
think of the slice working on the gaps between the elements (the ',') & 
not the element itself




-- 
In the long run we are all dead.
-- John Maynard Keynes
-- 
https://mail.python.org/mailman/listinfo/python-list