[issue26004] pip install lifetimes - throwing error and unable to install packages

2016-01-05 Thread Eryk Sun

Eryk Sun added the comment:

You can build NumPy with only a C compiler, but it won't have accelerated 
BLAS/LAPACK. However, lifetimes requires SciPy, which in turn requires Fortran. 
This is a common requirement with a lot of the scientific-computing stack, so 
you may as well choose a complete solution such as Anaconda.

That said, if you just need a few packages, then Christoph Gohlke provides an 
extensive collection of wheels [1]. For example, I have a directory with the 
following wheels downloaded from Christoph's site:

C:\>dir /b Z:\Python\wheel
matplotlib-1.5.0-cp35-none-win_amd64.whl
numpy-1.10.2+mkl-cp35-none-win_amd64.whl
pandas-0.17.1-cp35-none-win_amd64.whl
scipy-0.16.1-cp35-none-win_amd64.whl

I'll test installing lifetimes and matplotlib in a virtual environment:

C:\>py -3 -m venv --symlinks C:\Temp\env35
C:\>C:\Temp\env35\Scripts\activate.bat

The command-line option "-f directory" makes pip look for packages in a local 
directory: 

(env35) C:\>pip install -f Z:\Python\wheel lifetimes matplotlib
Collecting lifetimes
  Using cached Lifetimes-0.1.6.3.tar.gz
Collecting matplotlib
Collecting numpy (from lifetimes)
Collecting scipy (from lifetimes)
Collecting pandas>=0.14 (from lifetimes)
Collecting pyparsing!=2.0.4,>=1.5.6 (from matplotlib)
  Downloading pyparsing-2.0.7-py2.py3-none-any.whl
Collecting pytz (from matplotlib)
  Using cached pytz-2015.7-py2.py3-none-any.whl
Collecting python-dateutil (from matplotlib)
  Using cached python_dateutil-2.4.2-py2.py3-none-any.whl
Collecting cycler (from matplotlib)
  Downloading cycler-0.9.0-py2.py3-none-any.whl
Collecting six>=1.5 (from python-dateutil->matplotlib)
  Using cached six-1.10.0-py2.py3-none-any.whl
Installing collected packages: numpy, scipy, six, python-dateutil,
pytz, pandas, lifetimes, pyparsing, cycler, matplotlib
  Running setup.py install for lifetimes
Successfully installed cycler-0.9.0 lifetimes-0.1.6.3
matplotlib-1.5.0 numpy-1.10.2 pandas-0.17.1 pyparsing-2.0.7
python-dateutil-2.4.2 pytz-2015.7 scipy-0.16.1 six-1.10.0

[1]: http://www.lfd.uci.edu/~gohlke/pythonlibs

--
nosy: +eryksun

___
Python tracker 

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



[issue26013] Pickle protocol 2.0 not loading in python 3.5

2016-01-05 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Thank you for your report Anil.

Python 3.4.3 creates incorrect pickle with protocol 2 (it can't be load in 
Python 2). issue18473 fixed pickling with protocol 2 in Python 3, but broke 
loading broken pickles created in unpatched versions of Python 3.

Here is a patch that allows to load such broken pickles.

But it is too late to fix Python 3.4, it can get only security fixes. You have 
Celery specific workaround. More general workaround is to update 
_compact_pickle.IMPORT_MAPPING, e.g.:

import _compact_pickle
_compact_pickle.IMPORT_MAPPING.update({
'UserDict': 'collections',
'UserList': 'collections',
'UserString': 'collections',
'whichdb': 'dbm',
'StringIO':  'io',
'cStringIO': 'io',
})

Note that you have to set mapping not just for one module name like 'UserList', 
but for all 'UserDict', 'UserList', and 'UserString', because it is not 
predicable to what module name 'collections' is mapped in Python 3.4.3.

--
assignee:  -> serhiy.storchaka
components: +Library (Lib)
keywords: +patch
nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka
stage:  -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file41504/unpickle_broken_import.patch

___
Python tracker 

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



[issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636

2016-01-05 Thread Nikolaus Rath

Nikolaus Rath added the comment:

Stefan, sorry for ignoring your earlier reply. I somehow missed the question at 
the end.

I believe that users of the Python module are *not* expected to make use of the 
WANT_READ, WANT_WRITE flags. Firstly because the documentation (of Python's ssl 
module) doesn't say anything about that, and secondly because the code that's 
necessary to handle these flags is a prime example for complexity that is 
imposed by the C API that should be hidden to Python users.

That said, could you give a more specific reference to the O'Relly book (and 
maybe even page or chapter)? At the moment it's a little hard for me to follow 
the rest of your message. 

Essentially, if I'm trying to write to a non-blocking, Python SSL socket, I 
would expect that this either succeeds or raises SSL_WANT_WRITE/READ. Not 
having read the book, it seems to me this is the only information that's useful 
to a Python caller. In what situation would you need the more exact state that 
your C example tracks?

--

___
Python tracker 

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



[issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments

2016-01-05 Thread Brett Cannon

New submission from Brett Cannon:

If you look at https://docs.python.org/3/installing/index.html it lists two 
commands:

python -m pip install SomePackage==1.0.4# specific version
python -m pip install 'SomePackage>=1.0.4'  # minimum version

If you notice that beyond the change from `==` to `>=`, you will notice one 
quotes its argument while the other one doesn't. This is a UNIX shell thing due 
to what `>` means. But if you don't know how the UNIX shell works this could be 
easily overlooked. It would be best to simply quote both examples and avoid 
people messing up by leaving off the quotes.

--
assignee: docs@python
components: Documentation
messages: 257536
nosy: alexis, brett.cannon, docs@python, dstufft, eric.araujo, lemburg, 
ncoghlan, paul.moore, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Update https://docs.python.org/3/installing/index.html to always quote 
arguments
type: enhancement

___
Python tracker 

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



[issue26016] io.TextIOWrapper.tell() report 65bit number when mix readline() + tell()

2016-01-05 Thread STINNER Victor

STINNER Victor added the comment:

Yeah, it's expected that tell() can return big numbers. It returns a black box 
"cookie".

https://docs.python.org/dev/library/io.html#id3

https://docs.python.org/dev/library/io.html#io.TextIOWrapper

--
nosy: +haypo

___
Python tracker 

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



[issue25940] SSL tests failed due to expired svn.python.org SSL certificate

2016-01-05 Thread Jason Madden

Changes by Jason Madden :


--
nosy: +jmadden

___
Python tracker 

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



[issue26015] Add new tests for pickling iterators of mutable sequences

2016-01-05 Thread Serhiy Storchaka

New submission from Serhiy Storchaka:

Proposed patch updates tests for iterators of mutable sequences. Now tested 
iterators in all four states (initial, running, empty and exhausted), and 
tested that unpickled iterator is linked with a sequence, not with an 
independed copy (as in case of dict iterators).

Note that there is a difference in the behavior of exhausted array iterator 
from other iterators. Perhaps this should be changed.

--
components: Tests
files: iterators_pickle_tests.patch
keywords: patch
messages: 257530
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add new tests for pickling iterators of mutable sequences
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41507/iterators_pickle_tests.patch

___
Python tracker 

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



[issue25776] More compact pickle of iterators etc

2016-01-05 Thread Serhiy Storchaka

Changes by Serhiy Storchaka :


--
dependencies: +Add new tests for pickling iterators of mutable sequences

___
Python tracker 

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



[issue26016] io.TextIOWrapper.tell() report 65bit number when mix readline() + tell()

2016-01-05 Thread EcmaXp

이시만 (EcmaXp) added the comment:

second fp.readline() # '..\n' is actaully '...\n'
mistake

--

___
Python tracker 

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



[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

2016-01-05 Thread Alessandro Cucci

Alessandro Cucci added the comment:

up

--

___
Python tracker 

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



[issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments

2016-01-05 Thread Zachary Ware

Zachary Ware added the comment:

I'd also suggest using double quotes ("); single quotes don't work on Windows.

C:\>echo 'test>=test'

C:\>dir /b test*
test'

C:\>type "test'"
'test

--
nosy: +zach.ware

___
Python tracker 

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



[issue20440] Use the Py_SETREF macro

2016-01-05 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

The commit doesn't include changes for dictobject.c, setobject.c and 
_sqlite/cache.c (I had forgot to exclude them from the patch before uploading). 
Dict and set code is performance critical, and using Py_XDECREF instead of 
Py_DECREF can affect performance. The code in _sqlite would use Py_SETREF in 
less obvious way, it is better to left it as is.

--
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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Guido van Rossum

Guido van Rossum added the comment:

I'm regenerating the patch in the hope that it will trigger the code review 
hook.

--
Added file: http://bugs.python.org/file41508/abarnert-patch-regenerated.diff

___
Python tracker 

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



[issue20440] Use the Py_SETREF macro

2016-01-05 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 1118dfcbcc35 by Serhiy Storchaka in branch 'default':
Issue #20440: Cleaning up the code by using Py_SETREF.
https://hg.python.org/cpython/rev/1118dfcbcc35

--

___
Python tracker 

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



[issue26013] Pickle protocol 2.0 not loading in python 3.5

2016-01-05 Thread Anil Kulkarni

Anil Kulkarni added the comment:

Hi Serhiy,

I have done some more investigation this morning and I have come across two 
distinct issues.

The first is that pickles (specifically the pickle in my earlier message) 
created in python 3.0->3.4.3 do not load on python 2.7.10. The exception is 
3.5.1, which produces a pickle that DOES load on 2.7.10
This is unfortunate but not a regression

The second issue is that pickles created by python 3.0->3.4.3 do NOT load in 
python 3.5

This is a regression, in the sense that the pickle created by 3.0->3.4.3 is 
compatible with every other version of python (I haven't tested every single 
combination here, but several)

>From the language perspective, it may be that 3.4.X has incorrect code, but 
>from a compatibility perspective, 3.5 is breaking the promise that pickles are 
>compatible across versions of python.

I write this as justification that python 3.5 should fix this regression in 
compatibility with 3.0 -> 3.4.3. At the very least 3.5 should have a shim 
behavior to fallback and allow it to import these pickles correctly.

Thanks,
Anil

--

___
Python tracker 

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



[issue26016] io.TextIOWrapper.tell() report 65bit number when mix readline() + tell()

2016-01-05 Thread EcmaXp

New submission from 이시만 (EcmaXp):

I did test on 
- Python 3.5.1 on Windows 64 Bit and 32 Bit (Machine A)
- Python 3.4.4 on Windows 32 Bit (Machine A)
- Python 3.4.3+ on Ubuntu 15.10 64 Bit (Virtual Machine on Machine A)
- Python 3.4.2 on Machine B and C
- Python 3.3.5 on Windows 32 Bit (Machine A)

I did test but not produce bug. (report 8 correctly)
- Python 3.2.5 on Windows 32 Bit (Machine A)
- Python 3.1.4 on Windows 32 Bit (Machine A)
- Python 2.7.10 on Windows 64 Bit (Machine A) 

Machine A: i7-5775C with Windows 10 (build 10586.36) 64 Bit
Machine B: http://www.tutorialspoint.com/execute_python3_online.php
Machine C: https://repl.it/languages/python3

Code are here

import io
with io.TextIOWrapper(io.BytesIO(b'.\r\n...\r\n\r\n\r\n')) as fp:
fp.readline() # '.\n'
fp.readline() # '..\n'
print(fp.tell()) # 18446744073709551628 = 0x10009

Not only those string produce bug, also adding more dot make produce bug 
sometimes.

--
components: IO, Library (Lib)
messages: 257531
nosy: 이시만 (EcmaXp)
priority: normal
severity: normal
status: open
title: io.TextIOWrapper.tell() report 65bit number when mix readline() + tell()
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Note that setting some special methods (such as __copy__, __deepcopy__, 
__reduce_ex__, __reduce__, __setstate__, etc) to None has different meaning. 
The value None is just ignored and corresponding operation is fall back to 
other methods. For example copy.deepcopy() uses __reduce_ex__ if __deepcopy__ 
is None, __reduce__ if __reduce_ex__ is None.

May be this should be changed.

--

___
Python tracker 

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



[issue26016] io.TextIOWrapper.tell() report 65bit number when mix readline() + tell()

2016-01-05 Thread Martin Panter

Martin Panter added the comment:

The documentation for tell() 
 says that it 
returns an opaque number. Depending on the codec used, it might have to record 
the state of the text decoder, CRLF decoder, byte position, etc, all in that 
number. So I don’t think the return value being large is a bug.

Perhaps the change in behaviour from Python 2 is due to Issue 4. Also, 
Issue 25849 was recently opened about text file seeking.

--
nosy: +martin.panter

___
Python tracker 

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



[issue25637] Move non-collections-related ABCs out of collections.abc

2016-01-05 Thread Guido van Rossum

Guido van Rossum added the comment:

Honestly I think this such a slippery slope that I prefer keeping them in 
collections.abc. The main reason that we have Iterable and Iterator is that 
they are closely related to real collections (e.g. Sequence, Set, Mapping).  
And generators are related to iterators.  And so on.  To me the force that 
wants to keep abc.py purely about *implementing* ABCs is stronger than the 
desire to have only things that really are ABCs for collection types in 
collections.abc.

The types.py module is a bunch of crap that we can't get rid of yet but it 
should not be used for anything new.

--
nosy: +gvanrossum

___
Python tracker 

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



[issue22558] Missing hint to source code - complete

2016-01-05 Thread Terry J. Reedy

Terry J. Reedy added the comment:

Guido, should we take your comment as approving linking every source, as 
opposed to only some?  This scope issue is the main sticking point for this 
issue.  Otherwise, the standard patch is 3 easy new lines after the :synopsis: 
(and any 'New in Version x.y' note for the module -- see argparse).  The 
following is Benjamin's patch for #22528.

--- a/Doc/library/pdb.rst
+++ b/Doc/library/pdb.rst
@@ -6,6 +6,9 @@
 .. module:: pdb
:synopsis: The Python debugger for interactive interpreters.

+**Source code:** :source:`Lib/pdb.py`
+
+--

 .. index:: single: debugging
 
Friedrich, were you planning to write a patch, once the list of modules is 
decided on?  Or should we invite submissions on the core-mentorship list?

--

___
Python tracker 

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



[issue26020] set_display evaluation order doesn't match documented behaviour

2016-01-05 Thread Raymond Hettinger

Raymond Hettinger added the comment:

The culprit is the BUILD_SET opcode in Python/ceval.c which unnecessarily loops 
backwards (it looks like it was copied from the BUILD_TUPLE opcode).

--
assignee: docs@python -> rhettinger
nosy: +rhettinger

___
Python tracker 

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



[issue22558] Missing hint to source code - complete

2016-01-05 Thread Guido van Rossum

Guido van Rossum added the comment:

It's fine to add a source link to any module for which there is Python source 
code.  I suppose this adds a slight maintenance burden when a module moves 
(e.g. when a module is turned into a package, or when the subdirectory 
structure of the Lib directory changes).

I'm a little confused about the "New in x.y" note -- why is that connected to 
the source code link?

Of course, the source tells a different story from the docs -- e.g. 
undocumented implementation details may change, and sometimes the source is 
hard to understand (on occasion I've been confused myself :-).  But Python is 
open source, so people can always read the source -- I don't see why we should 
try to make reading the source harder for people who don't yet have the chops 
to just read it on their own computer!

--

___
Python tracker 

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



[issue26020] set_display evaluation order doesn't match documented behaviour

2016-01-05 Thread Hamish Campbell

New submission from Hamish Campbell:

It looks like the behaviour of set displays do not match behaviour in some 
cases. The documentation states:

"A set display yields a new mutable set object, the contents being specified by 
either a sequence of expressions or a comprehension. When a comma-separated 
list of expressions is supplied, its elements are evaluated from left to right 
and added to the set object. When a comprehension is supplied, the set is 
constructed from the elements resulting from the comprehension."

Note the following:

   >>> foo = { True, 1 }
   >>> print(foo)
   {1}

However, if we add elements 'left to right':

   >>> foo = set()
   >>> foo.add(True)
   >>> foo.add(1)
   >>> print(foo)
   {True}

Note that similar documentation for dict displays produces the expected result.

"If a comma-separated sequence of key/datum pairs is given, they are evaluated 
from left to right to define the entries of the dictionary: each key object is 
used as a key into the dictionary to store the corresponding datum. This means 
that you can specify the same key multiple times in the key/datum list, and the 
final dictionary’s value for that key will be the last one given."

   >>> foo = {}
   >>> foo[True] = 'bar'
   >>> foo[1] = 'baz'
   >>> print(foo)
   {True: 'baz'}

Which matches the dict display construction:

   >>> foo = { True: 'bar', 1: 'baz'}
   >>> print(foo)
   {True: 'baz'}

Note that I've tagged this as a documentation bug, but it seems like the 
documentation might be the preferred implementation.

--
assignee: docs@python
components: Documentation
messages: 257579
nosy: Hamish Campbell, docs@python
priority: normal
severity: normal
status: open
title: set_display evaluation order doesn't match documented behaviour
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, 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



[issue26020] set_display evaluation order doesn't match documented behaviour

2016-01-05 Thread Hamish Campbell

Hamish Campbell added the comment:

Note also the differences here:

   >>> print(set([True, 1]))
   {True}
   >>> print({True, 1})
   {1}
   >>> print({x for x in [True, 1]})
   {True}

--

___
Python tracker 

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



[issue26020] set_display evaluation order doesn't match documented behaviour

2016-01-05 Thread Hamish Campbell

Hamish Campbell added the comment:

Apologies, that first line should read "It looks like the documentation of set 
displays do not match behaviour in some cases".

--

___
Python tracker 

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



[issue26020] set_display evaluation order doesn't match documented behaviour

2016-01-05 Thread Emanuel Barry

Emanuel Barry added the comment:

Set displays appear to be the culprit here:

>>> class A:
...   count = 0
...   def __init__(self):
... self.cnt = self.count
... type(self).count += 1
...   def __eq__(self, other):
... return type(self) is type(other)
...   def __hash__(self):
... return id(type(self))
...
>>> e={A(), A(), A(), A(), A()}
>>> e
{<__main__.A object at 0x002BB2B0>}
>>> list(e)[0].cnt
4
>>> list(e)[0].count
5
>>> A.count = 0
>>> q=set([A(), A(), A(), A(), A()])
>>> q
{<__main__.A object at 0x002BB310>}
>>> list(q)[0].cnt
0
>>> list(q)[0].count
5

I'm guessing this is an optimization and/or set displays just don't keep 
ordering at definition time.

Do you have a use case where `x == y`/`hash(x) == hash(y)` does not mean that 
`x` and `y` should be interchangeable? True and 1 are 100% interchangeable, 
minus their str() output, and my example is very unlikely to ever appear in 
actual code.

Probably just better to fix the docs to specify that sets literals don't check 
ordering.

--
nosy: +ebarry
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

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



[issue26020] set_display evaluation order doesn't match documented behaviour

2016-01-05 Thread Raymond Hettinger

Changes by Raymond Hettinger :


--
keywords: +patch
Added file: http://bugs.python.org/file41514/build_set.diff

___
Python tracker 

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



[issue26019] collections.abc documentation incomplete

2016-01-05 Thread Andrew Barnert

Andrew Barnert added the comment:

The attached patch is, I think, the smallest change that includes all the 
necessary information.

Of course it will need to be redone if #25958 goes through, with a 
version-changed note explaining that prior to 3.6 some of the implicit ABCs 
(maybe with a list) treated None as an abstract method implementation while 
others didn't. So, this patch is basically a throwaway. But any review comments 
would still be useful, of course.

--
keywords: +patch
Added file: http://bugs.python.org/file41513/patch26019.diff

___
Python tracker 

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



[issue22831] Use "with" to avoid possible fd leaks

2016-01-05 Thread Martin Panter

Martin Panter added the comment:

I had another look at the five patches you mentioned. I made a couple review 
comments about expanding the scope of some “with” statements.

There are a couple changes that add explicit file closing, where it was 
previously up to the garbage collector. I.e. code like open(...).read(). I 
think those changes are the most important, although they are scattered over 
the various patches.

On the other hand, some of the changes in the test suite, particularly 
test_dbm_dumb.py and test_xmlrpc.py, hardly seem worth it. The main benefit of 
the “with” statement would be if the test code fails, which hopefully won’t 
happen that often. :)

In the test suite, perhaps it would be better to call self.addCleanup(f.close) 
or similar in many cases. That way you wouldn’t need contextlib.closing() as 
much, and there would be less file history clutter and “cavern code”, due to 
the extra indentation.

--

___
Python tracker 

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



[issue25940] SSL tests failed due to expired svn.python.org SSL certificate

2016-01-05 Thread Martin Panter

Martin Panter added the comment:

After looking into the unwrap() problem more, I think I understand the problem, 
and believe making the server call unwrap() is the correct way forward. 
SSL_ERROR_SYSCALL is Open SSL’s way of saying the connection was shut down 
insecurely (among other things). So I propose local-server.v2.patch which 
passes all the tests without hanging.

I am inclined to commit my first patch soon, which is fairly simple and should 
make the buildbots happy. Then people can have a chance to review the second 
(now third) patch, which is more involved.

Does the problem really need to be fixed in the 3.2 branch, or is 3.5+ and 2.7 
good enough?

--
Added file: http://bugs.python.org/file41515/local-server.v2.patch

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Andrew Barnert

Andrew Barnert added the comment:

The second patch takes into account all the issues raised by Martin and Guido, 
as well as some other changes that didn't make it into the first patch because 
Windows hates me. And it should be flattened into a single commit, and 
therefore should hopefully work with Rietveld out of the box. It passes the 
test suite on Windows and Cygwin (and on OS X, but that's a slightly older 
version of the changes than what's in this flattened patch).

I think it's still an open question whether Reversible should inherit Iterable. 
In the current patch, as in the first, it does.

I'll go over Serhiy's Reitveld comments to see if there's anything I missed, 
and, if so, address it in a third attempt.

On Serhiy's test suggestions:

 * I don't think we need to repeat the same tests on every ABC. That seems more 
likely to introduce copy-paste bugs than to catch anything, especially since 
the ABCs now all share the same code, but the tests couldn't.

 * Likewise for adding repetitive tests on more __spam__, __ispam__, and 
__rspam__ methods.

 * However, he's definitely right that there are other kinds of fallback worth 
testing, like __ne__ -> __eq__. I'll review the different kinds of fallback 
more carefully and make sure we have tests for each case.

--
Added file: http://bugs.python.org/file41509/patch2.diff

___
Python tracker 

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



[issue22268] add dedicated functions mrohasattr and mrogetattr

2016-01-05 Thread Andrew Barnert

Andrew Barnert added the comment:

See #25958, which incorporates a similar refactoring in service of making all 
of the subclasshooks in collections.abc handle None the same way.

We definitely do want something public in the abc module like this, rather than 
the private function in collections.abc that I wrote, especially given the 
discussion about moving a bunch of the ABCs to other modules.

--
nosy: +abarnert

___
Python tracker 

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



[issue22268] add dedicated functions mrohasattr and mrogetattr

2016-01-05 Thread Guido van Rossum

Guido van Rossum added the comment:

Honestly I don't think this is worth it. The proposed functions seem to fall 
firmly in the territory of "not every three useful lines of code are worth a 
stdlib function".

--
nosy: +gvanrossum

___
Python tracker 

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



[issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636

2016-01-05 Thread Stefan Krah

Stefan Krah added the comment:

https://books.google.com/books?id=IIqwAy4qEl0C_esc=y , page 159 ff.

Modules/_ssl.c:_ssl__SSLSocket_write_impl() just raises
PySSLWantReadError etc. if the socket is non-blocking.

IOW, it's a thin wrapper around SSL_write().

So yes, I think you do need complete error handling on
the Python level.

--

___
Python tracker 

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



[issue14574] SocketServer doesn't handle client disconnects properly

2016-01-05 Thread John Szakmeister

John Szakmeister added the comment:

FWIW, I'm seeing the same issue as Jason too, and his solution seems reasonable 
to me.

--
nosy: +jszakmeister

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Raymond Hettinger

Raymond Hettinger added the comment:

There is already a precedent for None, but it would have been nicer to use 
NotImplemented.

--
nosy: +rhettinger

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Needed tests for Hashable, Awaitable, Coroutine, AsyncIterable, AsyncIterator, 
Iterator, Generator, Sized, Container, Callable.

The patch adds some tests for __iadd__ and __eq__. I think needed tests for a 
number of other special methods. In particular should be tested a classes 
without __iadd__, but with __add__ but to None; with __radd__, but with __add__ 
set to None; without __add__, but with __radd__ set to None; with __eq__, but 
with __ne__ set to None, etc.

Added other comments on Rietveld.

--

___
Python tracker 

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



[issue20440] Use the Py_SETREF macro

2016-01-05 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

The final patch replaces the code that equivalent to the Py_SETREF macro by 
using the Py_SETREF macro. There are no bugs, the patch only makes the correct 
code cleaner. If I'll not got a review, I'll just close this issue.

--
versions:  -Python 2.7, Python 3.5
Added file: http://bugs.python.org/file41505/py_setref_extra3.patch

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

What if use None and NotImplemented as different signals: "not defined here so 
fall back on either a superclass or a different protocol", and "not defined 
here so fail without falling back"?

--

___
Python tracker 

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



[issue25637] Move non-collections-related ABCs out of collections.abc

2016-01-05 Thread Brett Cannon

Brett Cannon added the comment:

So leave Callable and Coroutine there and if I add a context manager ABC put it 
in collections.abc as well? Or should we put Callable and Coroutine in 
functools and a context manager one in contextlib (or Coroutine in asyncio)?

--

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Guido van Rossum

Guido van Rossum added the comment:

No. Simply No. Nobody will be able to remember which means which.

--

___
Python tracker 

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



[issue25609] Add a ContextManager ABC and type

2016-01-05 Thread Brett Cannon

Brett Cannon added the comment:

In issue #25637, Guido said he didn't want to move stuff out of 
collections.abc, so the context manager ABC will go into contextlib.

To answer Martin's point, I could make __exit__ abstract to begin with to make 
people override it properly. The only reason I thought of providing a default 
implementation is that it inherently isn't required to be implemented to match 
the context manager interface/protocol. But as you pointed out, the usefulness 
of a context manager is derived from doing stuff in __exit__(), so I will make 
it abstract.

--
dependencies: +Move non-collections-related ABCs out of collections.abc

___
Python tracker 

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



[issue25609] Add a ContextManager ABC and type

2016-01-05 Thread Brett Cannon

Changes by Brett Cannon :


--
assignee:  -> brett.cannon

___
Python tracker 

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



[issue26013] Pickle protocol 2.0 not loading in python 3.5

2016-01-05 Thread Anil Kulkarni

Anil Kulkarni added the comment:

Ah, sorry I misunderstood. Thanks for the quick turnaround!

--

___
Python tracker 

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



[issue25637] Move non-collections-related ABCs out of collections.abc

2016-01-05 Thread Guido van Rossum

Guido van Rossum added the comment:

I think ContextManager should be in contextlib. I don't want to put
anything in functools. Coroutine doesn't belong in asyncio, it's more
fundamental (closely related to Generator).

--

___
Python tracker 

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



[issue25637] Move non-collections-related ABCs out of collections.abc

2016-01-05 Thread Brett Cannon

Brett Cannon added the comment:

Thanks for the input everyone!

--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

True, even I were not sure which should mean which. ;)

> When I manually trigger the code in typeobject.c:5827, I get a segfault;
I'm surprised no test triggered that.

I think this triggered one of Victor's guards, added to catch such sort of 
errors. In this case the function both raises an exception and returns a 
result. If not catch such sort of error, it can cause unexpected errors or very 
strange results during executing unrelated code, so crashing as early as 
possible is lesser evil.

--

___
Python tracker 

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



[issue26013] Pickle protocol 2.0 not loading in python 3.5

2016-01-05 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

I agree, and the provided is purposed to fix this issue. In the previous 
message I just proposed a workaround for those who can't wait 3.5.2.

--

___
Python tracker 

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



[issue26014] Guide users to the newer package install instructions

2016-01-05 Thread Nick Coghlan

New submission from Nick Coghlan:

The up to date module installation docs are at:

* https://docs.python.org/2/installing/index.html
* https://docs.python.org/3/installing/index.html

However, legacy deep links still resolve to the old docs:

* https://docs.python.org/2/install/index.html
* https://docs.python.org/3/install/index.html

Those link out to packaging.python.org, the link is buried in a longish note, 
rather than being highlighted as a more obvious See Also link.

The top level landing page in the Python 2.7 docs also still links to the 
legacy docs rather than the new ones, and the "(Legacy)" notation hasn't been 
appended to the headings on the legacy docs the way it has in 3.x.

There's a few long hanging fruit for cleanup here:

* add See Also links to the modern docs from the legacy docs
* append the (Legacy) suffix in the 2.x docs
* fix the 2.x top level docs page to link to the new docs rather than the 
legacy ones
* link to the legacy docs from the distutils package docs in 2.7 (as has 
already been done in 3.x)

--
assignee: docs@python
components: Documentation
messages: 257529
nosy: docs@python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Guide users to the newer package install instructions
type: enhancement

___
Python tracker 

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



[issue26018] documentation of ZipFile file name encoding

2016-01-05 Thread Serhiy Storchaka

Changes by Serhiy Storchaka :


--
stage:  -> needs patch

___
Python tracker 

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



[issue22558] Missing hint to source code - complete

2016-01-05 Thread Guido van Rossum

Guido van Rossum added the comment:

Actually uploading a patch for this should be easy, right?

--
keywords: +easy
nosy: +gvanrossum

___
Python tracker 

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



[issue6500] urllib2 maximum recursion depth exceeded

2016-01-05 Thread Berker Peksag

Changes by Berker Peksag :


--
resolution:  -> fixed
stage: commit 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



[issue26018] documentation of ZipFile file name encoding

2016-01-05 Thread Martin von Gagern

New submission from Martin von Gagern:

https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.write writes:

“Note: There is no official file name encoding for ZIP files. If you have 
unicode file names, you must convert them to byte strings in your desired 
encoding before passing them to write(). WinZip interprets all file names as 
encoded in CP437, also known as DOS Latin.”

I think this is wrong in many ways. Firstly, APPNOTE.TXT used to explicitely 
define CP437 as the standard, and it's still the standard in the absence of 
general purpose bit 11 and a more specific description using the 0x0008 Extra 
Field. On the other hand, we do have that general purpose bit these days, so 
there are now not just one but two well-defined file name encodings. And 
thirdly, encoding the string to bytes as suggested will in fact lead to a run 
time error, since ZipInfo expects to do this conversion itself.

See work towards issue1734346, starting at commit 8e33f316ce14, for details on 
when this was addressed in the source code.

--
assignee: docs@python
components: Documentation
messages: 257567
nosy: docs@python, gagern
priority: normal
severity: normal
status: open
title: documentation of ZipFile file name encoding
type: behavior
versions: Python 3.5

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Guido van Rossum

Guido van Rossum added the comment:

FWIW, Martin's review was much more extensive. I'm looking forward to the flat 
version of your next patch, Andrew!

--

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Guido van Rossum

Guido van Rossum added the comment:

In response to Serhiy's comment regarding __copy__ etc.: while the
distinction is somewhat unfortunate, I think it's too late to make this
more consistent. I think it's fine that the special methods used by copy
and pickle protocols behave somewhat differently -- that's a totally
different area anyways (and not directly supported by the core language).
In contrast, __hash__, __iter__, __contains__, __reversed__, __iadd__ etc.
are much more core to the language (representing either builtin functions
or operations). Plus here we really need a way to signal the difference
between "not defined here so fall back on either a superclass or a
different protocol" and "defined here as not existing so cause an error
when used". So I don't think there's anything actionable here.

--

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Guido van Rossum

Guido van Rossum added the comment:

The idea of using NotImplemented was already discussed (IIR in
python-ideas). I really don't like it.

--

___
Python tracker 

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



[issue25958] Implicit ABCs have no means of "anti-registration"

2016-01-05 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Without tests you can't be sure that there is no special case in some abstract 
classes or operators, or that it can't be introduced in future. To decrease the 
copy-pasting you can use code generation for testing.

But I don't know what is the best place for tests. Tests for special methods 
are scattered though different files: test_binop, test_class, test_compare, 
test_descr, test_richcmp, test_augassign, test_contains, test_iter, etc.

--

___
Python tracker 

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



[issue17394] Add slicing support to collections.deque

2016-01-05 Thread Serhiy Storchaka

Changes by Serhiy Storchaka :


Removed file: http://bugs.python.org/file41495/deque_slices.patch

___
Python tracker 

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



[issue17394] Add slicing support to collections.deque

2016-01-05 Thread Serhiy Storchaka

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file41506/deque_slices.patch

___
Python tracker 

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



[issue26010] document CO_* constants

2016-01-05 Thread Yury Selivanov

Yury Selivanov added the comment:

> This is a follow up to issue #26010.

The correct issue # is 25813

--

___
Python tracker 

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



[issue26019] collections.abc documentation incomplete

2016-01-05 Thread Andrew Barnert

New submission from Andrew Barnert:

Some of the modules in collections.abc have a subclass hook that implicitly 
registers any type that declares the right methods, like Iterator. Others do 
not, like Sequence. For those that do have the hook, it's not always obvious 
what methods are tested. And some of them test the methods for truthiness, 
others only for existence (although #25958 will fix that last bit).

The documentation doesn't even mention this, much less describe which ABCs are 
of which kind.

For someone who just wants to know how to write isinstance(arg, Iterable), 
that's fine. But anyone who wants to create new classes, or integrate 
third-party classes that weren't ABC-friendly, has to read the collections.abc 
module source to figure out what they want to do.

--
assignee: docs@python
components: Documentation
messages: 257577
nosy: abarnert, docs@python
priority: normal
severity: normal
status: open
title: collections.abc documentation incomplete
type: enhancement
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



[issue25940] SSL tests failed due to expired svn.python.org SSL certificate

2016-01-05 Thread Martin Panter

Martin Panter added the comment:

Koobs: What thing are you suggesting to mock? The remote server perhaps, which 
is what I want to do too?

Here is a patch that implements my local SSL server idea by reusing 
ThreadedEchoServer.

There is one problem with local-server.patch, and I don’t know how to fix it 
properly. At the end of test_bio_handshake() and test_bio_read_write_data(), 
the unwrap() call keeps raising SSL_ERROR_SYSCALL and the test hangs in an 
infinite loop. I could work around this by making the server call unwrap() 
before shutting the socket down. But it would be better to fix ssl_io_loop() if 
anyone understands what is going wrong.

--
Added file: http://bugs.python.org/file41512/local-server.patch

___
Python tracker 

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