[issue26013] Pickle protocol 2.0 not loading in python 3.5

[Anil Kulkarni]

New submission from Anil Kulkarni:

Pickles created with python 3.4.X will not load with python 3.5.X if they 
include a collections.OrderedDict

To reproduce this issue, simply create a pickle of an OrderedDict on python 
3.4.3 with protocol=2 and try to open it on 3.5. I have included a simple 
script to demonstrate this issue.


I believe this is related to this bug: https://bugs.python.org/issue18473

As to the real-world implications: The python package Celery uses protocol=2 by 
default when serializing with pickle, and thus a celery web running 3.5 cannot 
receive the results of a worker running 3.4
For celery specifically, there is a workaround by setting the PICKLE_PROTOCOL 
environment variable, but this is a core python issue.

P.S. This is the first bug I've filed with python so please let me know if 
there's something else I should be including.

Thanks!

--
files: b.py
messages: 257524
nosy: anilredshift
priority: normal
severity: normal
status: open
title: Pickle protocol 2.0 not loading in python 3.5
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file41503/b.py

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

[Andrew Barnert]

Andrew Barnert added the comment:

> A Mercurial export patch should work with the Reitveld review thing if it is 
> a single revision (and based on a public revision).

Well, it's 7 separate commits on a work branch, so I could check in each piece 
and test it separately, and then I just compared the branch to its parent 
(default) for the export. But, as I said, I can flatten it into a single diff 
if the review system can't handle this way.

Sorry for making the first patch hard to review, and thanks for reviewing it 
anyway; I'll fix that with the next one.

> You have a stray print() call, probably in Hashable.__subclasshook__().

Thanks; fixed for the next patch.

> For a the do-nothing __reversed__() implementation, do you think “yield from 
> ()” would be clearer than “while False”? Or even “return iter(())”?

Maybe, but this way is identical to the definition for the do-nothing 
Iterable.__iter__.

> What’s the advantage of having Reversed inherit Iterable?

This was discussed briefly... somewhere, maybe the -ideas thread? 

Pro: If they were independent types, more people would probably register 
with/inherit from Reversible but not Iterable in error than intentionally.

Pro: One less thing for Sequence to inherit from. This was mentioned in the 
context of adding both Reversible and HalfSequence (or whatever it ends up 
being called): "class Sequence(Iterable, Reversible, HalfSequence, Sized, 
Container) seems a little much; "class Sequence(Reversible, HalfSequence, 
Sized, Container)" is slightly better.

Con: It's not completely impossible that a type could be reversible but not 
iterable. For example, you might have a reversible, and even 
indexable-with-negative-indicies-only, infinite collection of all the negative 
numbers. (But nobody could think of an actual _useful_ example of such a type.)

Those are all pretty trivial points. When Guido said someone needs to work out 
where Reversible fits into the hierarchy, and there'd been enough talk without 
a patch. So I looked at where the discussion seemed to be leaning, couldn't 
find any additional problems with it when I looked into it further, and did it 
that way. Guido said he liked it on the Reversible bug, so I did it the same 
way here.

So, no strong arguments or even feelings from anyone; if you've got one, 
definitely chime in.

> How does the subclass hook interact with classes that implement 
> __reversed__() but not __iter__()? I don’t see how the 
> self.assertFalse(issubclass(K, Reversible)) test could pass.

Exactly the same way Iterator's handles a class that defines __next__ but not 
__iter__.

I'll double-check that it actually is implemented right before the next patch 
(and verify that the tests run), but it should be "return _check_methods(C, 
"__reversed__", "__iter__").

> Should the new Reversed class be excluded from collections.__all__, or is it 
> not worth it?

It's Reversible, not Reversed. It's in __all__, and I'm pretty sure it should 
be there--if it's not worth exporting, it's not worth creating in the first 
place, or documenting, right?

> I find the lambda generator a bit quirky in test_Reversible(). Maybe it would 
> be better as an ordinary non-lambda generator with a yield statement.

This is taken from an identical test in test_Iterable, in the same file.

> It would be good to have a versionadded notice for Reversible. 

Definitely; thanks for the catch. I'll add that for the next version of the 
patch.

> I think there should also be one for allowing None for all special methods.

I'm assuming you mean in collections.abc, not in the data model, right?

The problem is where to put it. The collections.abc docs don't even mention 
that some of the ABCs have subclass hooks that detect "implicit subclasses", 
much less tell you which ones do and don't, much less tell you which among 
those that do treat None specially. Until we add that documentation, there's 
really nothing to contrast with.

Maybe this means we need another bug where we rewrite the collections.abc docs 
to include all that information, and in the new documentation we can note what 
prior versions of Python did (or maybe prior versions of CPython--I doubt any 
major implementations were different, but without checking them all I wouldn't 
want to guarantee that)?

> Instead of self.assertEqual(list(reversed(R())), list(reversed([]))), why not 
> check it is equal to an empty list directly?

This might be a case of following the parallelism with test_Iterable too far; I 
can change it.

> In test_contains.py, I would either write lambda: 0 in bc, or use the “with 
> self.assertRaises()” form.

That makes sense; I'll do it.

> Finally, if setting a binary operator method to None means that operation is 
> not available, I find it a bit surprising that doing this prevent the other 
> operand’s method from being tried. I guess you don’t want to change the 
> implementation, but perhaps the documentation of the binary operator methods 
> co

[issue26012] pathlib.Path().rglob() is fooled by symlink loops

[Guido van Rossum]

Guido van Rossum added the comment:

I agree it's easiest just not to traverse symlinks matching **. glob.py
avoids the errors (but not the senseless recursion) by simply ignoring
OSError coming out of listdir(). That might be a good idea anyways (it
might even be a simpler way to avoid the PermissionError reported in
#24120).

--

___
Python tracker 

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

[issue24733] Logically Dead Code

[Senthil Kumaran]

Senthil Kumaran added the comment:

Thanks for the report, Pankaj Sharma. Removed in 2.7.11+.

--
assignee:  -> orsenthil
nosy: +orsenthil
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

[issue24733] Logically Dead Code

[Roundup Robot]

Roundup Robot added the comment:

New changeset f2a846c1b593 by Senthil Kumaran in branch '2.7':
Issue24733 - Remove unreachable code in traceback.c
https://hg.python.org/cpython/rev/f2a846c1b593

--
nosy: +python-dev

___
Python tracker 

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

[issue26012] pathlib.Path().rglob() is fooled by symlink loops

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

glob.glob() just stops too deep recursion.

>>> import glob
>>> glob.glob('tmp/**/*')
['tmp/baz/baz']
>>> glob.glob('tmp/**/*', recursive=True)
['tmp/baz', 'tmp/baz/baz', 'tmp/baz/baz/baz', 'tmp/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 'tmp/baz/baz/baz/
 baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/ba
 z/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/ba
 
z/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz',
 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz']

--
nosy: +serhiy.storchaka

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

[Martin Panter]

Martin Panter added the comment:

A Mercurial export patch should work with the Reitveld review thing if it is a 
single revision (and based on a public revision). Or you could try getting a 
plain diff from the base revision. Or for changes that are independent, 
separate patches based off a common public revision. Please at least fold your 
fixup commits into the original commits; that would make it a lot easier to 
review.

You have a stray print() call, probably in Hashable.__subclasshook__().

For a the do-nothing __reversed__() implementation, do you think “yield from 
()” would be clearer than “while False”? Or even “return iter(())”?

What’s the advantage of having Reversed inherit Iterable? How does the subclass 
hook interact with classes that implement __reversed__() but not __iter__()? I 
don’t see how the self.assertFalse(issubclass(K, Reversible)) test could pass.

Should the new Reversed class be excluded from collections.__all__, or is it 
not worth it?

I find the lambda generator a bit quirky in test_Reversible(). Maybe it would 
be better as an ordinary non-lambda generator with a yield statement.

It would be good to have a versionadded notice for Reversible. I think there 
should also be one for allowing None for all special methods.

Instead of self.assertEqual(list(reversed(R())), list(reversed([]))), why not 
check it is equal to an empty list directly?

In test_contains.py, I would either write lambda: 0 in bc, or use the “with 
self.assertRaises()” form.

Finally, if setting a binary operator method to None means that operation is 
not available, I find it a bit surprising that doing this prevent the other 
operand’s method from being tried. I guess you don’t want to change the 
implementation, but perhaps the documentation of the binary operator methods 
could be clarified.

--
stage:  -> patch review
type:  -> enhancement

___
Python tracker 

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

[issue25711] Rewrite zipimport from scratch

[diana]

Changes by diana :


--
nosy: +diana

___
Python tracker 

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

[issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer

[Senthil Kumaran]

Senthil Kumaran added the comment:

SimpleHTTPServer is never meant to be used in production.

I was of the understanding that we already inform users about it in the 
documentation, but I do not find any such note. Only in wsgiref's 
simple_server.py example, we state that in the module header
https://hg.python.org/cpython/file/tip/Lib/wsgiref/simple_server.py#l1

For SimpleHTTPServer, we could add a similar warning in docs.

"SimpleHTTPServer is meant for demo purposes and does not implement the 
stringent security checks needed of real HTTP server. We do not recommend using 
this module directly in production."

If an alternate wording is desired, please suggest in that in comments.

--
nosy: +orsenthil

___
Python tracker 

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

[issue26012] pathlib.Path().rglob() is fooled by symlink loops

[Josh Rosenberg]

Josh Rosenberg added the comment:

So would the goal of a fix be something like dev/inode memoization to prevent 
traversing the same link twice? To provide an argument to prevent following 
symlinks at all (as in stuff like os.walk), possibly defaulting to 
followlinks=False? It looks like languages like Ruby never follow symlinks when 
performing recursive globs to avoid this issue ( 
https://stackoverflow.com/questions/357754/can-i-traverse-symlinked-directories-in-ruby-with-a-glob
 ). It's probably easiest to just block recursing through symlinks (at least by 
default); memoizing risks unbounded memory overhead for large directory trees.

--
nosy: +josh.r

___
Python tracker 

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

[issue26011] Document necesities for cmp argument of sorted

[Josh Rosenberg]

Josh Rosenberg added the comment:

The docstring doesn't give details, but many docstrings don't. The docs 
themselves do; not sure it's a good idea to expand every docstring into 
complete documentation; if you don't know the function you read the real docs, 
the docstrings are useful as a reminder for stuff like argument order and 
names, higher logic, etc., without getting into details.

cmp is almost certainly not going to be documented further in the docstrings; 
2.7 is in bug fix only mode IIRC (and even then, mostly security fix only), and 
tweaking docstrings that aren't wrong, just less detailed than you might like 
isn't likely to meet the bar.

--
nosy: +josh.r

___
Python tracker 

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

[issue23677] Mention dict and set comps in library reference

[Josh Rosenberg]

Josh Rosenberg added the comment:

Heck, with the addition of additional unpacking generalizations in 3.5, you can 
make an empty set even without a comprehension: {*()}

Not really recommending the "one-eyed monkey operator", but the addition of 
unpacking generalizations undoes several of the limits on literals that 
previously existed.

--
nosy: +josh.r

___
Python tracker 

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

[issue10496] Python startup should not require passwd entry

[Jonathon Reinhart]

Jonathon Reinhart added the comment:

I have another scenario where this happens: Running Python in a Docker 
container, passing the --user option to 'docker run'. This sets the UID in the 
container, which has its own /etc/passwd. Couple this with the fact that $HOME 
might not be set (e.g. when Python is invoked from SCons which deliberately 
clears the environment for sub-processes), and *boom*, Python is non-functional.

Regardless of where the fix is done, the ideal behavior is straightforward: if 
Python can't determine the home directory, don't try to add user site packages.

This bug is now over 5 years old, and people have identified real-life various 
scenarios where this bug manifests itself, and submitted patches. Could we 
please address this?

--
nosy: +Jonathon Reinhart

___
Python tracker 

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

[issue26012] pathlib.Path().rglob() is fooled by symlink loops

[Ned Deily]

Changes by Ned Deily :


--
nosy: +pitrou

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

[Andrew Barnert]

Andrew Barnert added the comment:

Is an hg export patch usable? If not, let me know and I'll flatten it.

Anyway, the attached patch fixes #25987 and #25864 as well as this one, as 
follows:

 * Every ABC in collections.abc that has a subclass hook now treats None as 
blocking, instead of a few checking falsiness and others not checking anything. 
(And all the hooks are now identical, which eliminates any unintended 
inconsistencies.)

 * collections.abc.Mapping.__reversed__ = None (fixes #25864).

 * collections.abc.Reversible added (fixes #25987).

 * iter(), reversed(), and in operator all have custom text in their TypeError 
instead of the generic "'NoneType' object is not callable".

 * Unit tests for all of the above, plus that None blocking also works 
appropriately (i.e., same as in CPython 2.3-3.6) for __spam__ -> __rspam__, 
__ispam__ -> __spam__.

  * I didn't try to write tests for _everything_ with fallback. For example, 
blocking fallback from __str__ to __repr__, or anything to do with __*attr*__, 
does work, but I can't think of any conceivable case where you'd ever do such a 
thing. (The fact that you can write a class that isn't repr-able isn't a 
feature of Python we want to guarantee, it's just a side-effect of other stuff 
that will hopefully never come up, so it seems wrong to write a unit test to 
guarantee it.)

 * Data Model docs document that you can set a special method to None to block 
behavior (including blocking fallback to old-style sequence protocol, 
inheritance from superclass, etc.).

(Note that this patch is not yet fully tested, because my Windows and Cygwin 
builds are for some reason taking forever. But if I don't post an update 
tomorrow, that will mean they passed the overnight tests. I doubt anyone was 
going to commit this tonight anyway, but, just in case...)

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

___
Python tracker 

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

[issue26012] pathlib.Path().rglob() is fooled by symlink loops

[Guido van Rossum]

Changes by Guido van Rossum :


--
components: +Library (Lib)

___
Python tracker 

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

[issue26012] pathlib.Path().rglob() is fooled by symlink loops

[Guido van Rossum]

New submission from Guido van Rossum:

I created a symlink loop as follows:

mkdir tmp
cd tmp
ln -s ../tmp baz
cd ..

Then I tried to list it recursively using rglob():

>>> list(pathlib.Path('tmp').rglob('**/*')

This caused an infinite regress:
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 1065, in rglob
for p in selector.select_from(self):
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 549, in _select_from
for p in successor_select(starting_point, is_dir, exists, listdir):
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 548, in _select_from
for starting_point in self._iterate_directories(parent_path, is_dir, 
listdir):
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 538, in 
_iterate_directories
for p in self._iterate_directories(path, is_dir, listdir):
[...]
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 538, in 
_iterate_directories
for p in self._iterate_directories(path, is_dir, listdir):
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 537, in 
_iterate_directories
if is_dir(path):
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 1303, in is_dir
return S_ISDIR(self.stat().st_mode)
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line , in stat
return self._accessor.stat(self)
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 371, in wrapped
return strfunc(str(pathobj), *args)
OSError: [Errno 62] Too many levels of symbolic links: 
'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz'

--
messages: 257511
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: pathlib.Path().rglob() is fooled by symlink loops
versions: 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

[issue24120] pathlib.(r)glob stops on PermissionDenied exception

[Guido van Rossum]

Guido van Rossum added the comment:

I just ran into this issue. What's keeping it from being committed, except 
perhaps that Antoine decided to leave core developments?

--
nosy: +gvanrossum

___
Python tracker 

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

[issue22062] Fix pathlib.Path.(r)glob doc glitches.

[Guido van Rossum]

Guido van Rossum added the comment:

Classifying as easy doc bug.

--
assignee:  -> docs@python
components: +Documentation
keywords: +easy
nosy: +docs@python, gvanrossum

___
Python tracker 

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

[issue25919] http.client PUT method ignores error responses sent immediatly after headers

[Martin Panter]

Martin Panter added the comment:

As I see it, if the client receives an early response (when 100-continue is not 
used) but needs to make more requests, the only choices are:

* Complete sending the request if possible, after which the connection may 
still be usable for a second request. But I’m not sure how many servers would 
support this; for your Microsoft server this would not be useful.

* Abort the connection and start a new one.

Perhaps the race condition would be more obvious if you sent the upload as a 
single 300 MiB bytes() object rather than a file. Then the sendall() call will 
be a 300 MiB chunk rather than 8 KiB. If the response is received after 
sendall() starts, I expect you will see the original two minute delay again. If 
this were plain TCP, you could replace sendall() with fine-grained select() and 
send() calls in a loop.

Here is a demonstration of the SSL renegotiation issue. I used separate client 
and server terminal windows. I don’t know if there is a way to force 
renegotiation purely in Python’s SSL module, so I used an external Open SSL 
server.

1: In the server window, start an SSL server on port 4433:
$ openssl s_server -cert Lib/test/keycert.pem 

2: In the client window, start a request in the Python interpreter. It will 
pause to read stdin:
>>> import http.client, ssl, sys
>>> context = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
>>> context.load_verify_locations("/usr/lib/python3.5/test/keycert.pem")
>>> conn = http.client.HTTPSConnection('localhost', 4433, context=context)
>>> conn.request("PUT", "/", headers={"Content-Length": "4"}, 
>>> body=sys.stdin.buffer)

3: In the server, the request header is received. Type lowercase “r” to force a 
renegotiation:
Secure Renegotiation IS supported
PUT / HTTP/1.1
Host: localhost:4433
Accept-Encoding: identity
Content-Length: 8

r
SSL_do_handshake -> 1

4: In Python, type in upload data and repeat Ctrl+D to signal EOF until the 
request() call stops reading from stdin and you get the Python prompt back:
abc  <== 3 letters + newline + Ctrl+D
>>> 

5: Notice that the no body has been uploaded to the server.

--

___
Python tracker 

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

[issue17633] zipimport's handling of namespace packages is incorrect

[Brett Cannon]

Brett Cannon added the comment:

Nope, looks like it worked! I will try to have a look at the patch some time 
this week.

And for future reference, you can also use 
https://docs.python.org/devguide/patch.html as a guide.

--
assignee:  -> brett.cannon

___
Python tracker 

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

[issue17633] zipimport's handling of namespace packages is incorrect

[Mike Romberg]

Mike Romberg added the comment:

Try issue17633-hg.diff.   Caution it was made after literally minutes of 
experience with hg.  :)

  I checked out the source applied the changes, compiled and ran 'make test' 
(gdb still fails), and did an hg commit.  The diff was made following the 
instructions here:

https://docs.python.org/devguide/gitdevs.html

  It seems to have worked.  But again, I have literally minutes of hg 
experience.  If this needs to be redone let me know.

--
Added file: http://bugs.python.org/file41501/issue17633-hg.diff

___
Python tracker 

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

[issue26011] Document necesities for cmp argument of sorted

[Karl Richter]

New submission from Karl Richter:

The docstring of `sorted` doesn't explain what can be passed to the `cmp` and 
`key` argument of `sorted`.

--
assignee: docs@python
components: Documentation
messages: 257505
nosy: docs@python, krichter
priority: normal
severity: normal
status: open
title: Document necesities for cmp argument of sorted
type: enhancement
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

[issue17633] zipimport's handling of namespace packages is incorrect

[Mike Romberg]

Mike Romberg added the comment:

Yes.  I can do this.  I've not used hg before.  But I bet I can figure it out.  
I'm assuming hg has a diff/pach genterator of some kind ('hg diff' perhaps).

  Lemme try and find the hg repository and check out a copy...

--

___
Python tracker 

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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Phil Thompson]

Phil Thompson added the comment:

Understood, but the only promise here is to call a function (with no arguments, 
and returning no result).

--

___
Python tracker 

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

[issue17633] zipimport's handling of namespace packages is incorrect

[Brett Cannon]

Brett Cannon added the comment:

Any chance you can do the diff against an hg checkout, Mike? That way we can 
use our review tool to do the code review, else we have to work only from the 
raw diff file which isn't as nice.

--

___
Python tracker 

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

[issue25813] co_flags section of inspect module docs out of date

[Georg Brandl]

Georg Brandl added the comment:

> It's all ready been superceeded, or haven't you woken up to that fact either?

Excuse me for not having all issues in my head.  (And that #26010 states that 
it's a followup to #26010 doesn't help.)

In the future, please accept that the core developers are who decide about 
issues being closed or not.  Submitters are only given privilege to close their 
own issues because it lightens the load on coredevs if issues become obsolete 
(and no, no answer in less than 30 days does not mean obsolete).  As I already 
said, abusing that privilege will eventually get you banned - so much the 
sooner with your past history taken into account.

--

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Andrew Barnert]

Andrew Barnert added the comment:

> My main concern about the documentation was that in your patch you say _all_ 
> special methods are now allowed to be None, but in your code you only check 
> __iter__(). This is adding new undocumented inconsistencies e.g. with 
> Iterable vs Container.

No it isn't. We already have undocumented inconsistencies between, e.g., 
Hashable vs. Container; we're just moving Iterable from one set to the other. 
(Notice that there's an even larger inconsistency between, e.g., Hashable and 
Container vs. Sequence and Set. As Guido suggests, that probably _does_ need to 
be fixed, but not as part of this bug, or #25958.)

And, as for the docs, it's already true that you can block fallback and 
inheritance of special methods by assigning them to None, but that isn't 
documented anywhere.

So, this bug doesn't add fix any of those inconsistencies, but it doesn't add 
any new ones, either. If you think we actually _need_ to fix them, see #25958 
as at least a starting point. (Notice that Guido seems to want that one fixed, 
so, assuming I can write a decent patch for it, this bug would then become a 
one-liner: "__reversed__ = None" inside Mapping.)

--

___
Python tracker 

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

[issue25813] co_flags section of inspect module docs out of date

[Mark Lawrence]

Mark Lawrence added the comment:

It's all ready been superceeded, or haven't you woken up to that fact either?

--
status: open -> closed

___
Python tracker 

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

[issue25813] co_flags section of inspect module docs out of date

[Georg Brandl]

Georg Brandl added the comment:

> For the final time,  *I* am the OP and not one of you could be bothered 
> before so this remains closed.

Are you quite all right?  Continuing behavior of that sort will get your 
tracker account disabled.

--
nosy: +georg.brandl
status: closed -> open

___
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

[Yury Selivanov]

New submission from Yury Selivanov:

Hi David,

This is a follow up to issue #26010.  Please review the attached patch.  I've 
skipped the CO_NESTED flag since it's no longer used, and CO_OPTIMIZED because 
I don't know too much about it.

--
keywords: +patch
Added file: http://bugs.python.org/file41500/Issue26010.patch

___
Python tracker 

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

[issue25813] co_flags section of inspect module docs out of date

[Yury Selivanov]

Changes by Yury Selivanov :


--
superseder:  -> document CO_* constants

___
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

[Yury Selivanov]

Changes by Yury Selivanov :


--
assignee: docs@python
components: Documentation
keywords: needs review
nosy: docs@python, r.david.murray, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: document CO_* constants
type: enhancement
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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Brett Cannon]

Brett Cannon added the comment:

It might not change the default behaviour, but we still have to make sure it 
works and doesn't accidentally break. If we add official support for a C API to 
specify callbacks to execute during interpreter startup before any stdlib 
Python code then we are making a promise that it will work and so we have to 
worry about it even if the vast majority of users will never use it.

--

___
Python tracker 

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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Phil Thompson]

Phil Thompson added the comment:

I don't see why it would be hard to test. The change suggested wouldn't alter 
the default behaviour at all.

--

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Martin Panter]

Martin Panter added the comment:

I’m sorry I only read your patch and did not see the NoLen class above Blocked. 
(I blame the lack of Reitveld review link.) I still think __getitem__() should 
have a valid signature, but I acknowledge that it’s not really your fault. :)

My main concern about the documentation was that in your patch you say _all_ 
special methods are now allowed to be None, but in your code you only check 
__iter__(). This is adding new undocumented inconsistencies e.g. with Iterable 
vs Container. Maybe it would be better to only say that setting __iter__ to 
None is supported, instead of setting any special method.

--

___
Python tracker 

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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Brett Cannon]

Brett Cannon added the comment:

I personally would rather wait until PEP 432 happens before adding any such 
hook. This sort of thing is extremely hard to test and the startup sequence for 
Python is already quite complicated and honestly too tightly bound to the 
magical sequence of steps it current has.

--

___
Python tracker 

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

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

[Steve Dower]

Steve Dower added the comment:

Since you're on Python 3.5, you'll need Visual Studio 2015 to build extensions.

However, since the extension in question is numpy, you'll need to find prebuilt 
binaries since you won't be able to compile it yourself just yet. I believe 
Continuum has builds for 3.5 in Anaconda now.

--

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

[Guido van Rossum]

Guido van Rossum added the comment:

I like all of that. Thanks!

--

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

[Andrew Barnert]

Andrew Barnert added the comment:

> I propose to solve the narrow problem by indeed supporting the setting of 
> certain special methods to None similar to __hash__. This should be limited 
> to those methods for which this adds value, e.g. where the complete absence 
> of the method causes a fall-back to a different API (e.g. __getitem__+__len__ 
> in the case of __reversed__) -- the None value should just block the fallback

I believe that currently, except for the minor problem in #25864, you can set 
any special method to None and it _will_ block any fallback (and also block 
inheritance, of course, the reason it's used with __hash__):

 * __iter__ and __reversed__ directly fall back to another method.

 * __contains__ falls back to iterating, which will indirectly fall back on 
__iter__ (or on __getitem__, of course).

 * __iadd__ and friends fall back on __add__ and friends.

 * __add__ and friends fall back on __radd__ (on the other operand, but 
typically it will be of the same type).

 * __lt__ and friends are similar to __add__.

 * __getattr__ and friends are a pile of special cases.

 * I think everything else doesn't have a fallback, and would just raise a 
TypeError anyway--although setting to None is still useful as a way to block 
inheritance, as used for __hash__.

In all cases, if the primary method exists but is None, the implementation will 
try to call it, and let the TypeError from NoneType.__call__ escape, which 
blocks the fallback. (And, of course, it blocks the MRO search for an inherited 
method.)

Of course the message is the useless and cryptic "'NoneType' object is not 
callable" rather than the nice one you get from hash. But technically, it's all 
already working as desired.

We probably need to document that setting special methods to None blocks any 
fallback implementation (both for people who write such classes, and to ensure 
that other Pythons do the same thing as CPython). 

Practically, I think we need to improve the error message for the ones that are 
likely to come up, but probably not for all of them. I think this means either 
just reversed, or reversed+iter, or maybe reversed+iter+in. (Plus hash, of 
course, but that code is already there.)

Also, I suppose we should have tests for this behavior.

> This will require some changes in the ABCs that test for the presence of a 
> given method (Iterable/__iter__, Container/__contains__, 
> Reversible/__reversed__ -- the latter ABC should be added) and in 
> implementations such as reversed(), iter() and 'in'. Maybe we should just do 
> this for every ABC in collections.abc (plus Reversible) that has a 
> __subclasshook__ that tests for the presence of the special method.

Now that I think about it, I'm +0.5 on changing all of them. Imagine, as a 
reader, trying to guess why some do the check and some don't.

Also, I think they should test for None instead of falsiness like Hashable 
does. (Hopefully nobody ever writes something that's falsey but callable, but 
why tempt fate?)

---

I'll write a patch that expands the #25864 patch:

 * collections.abc.Reversible added (as in #25987).

 * All collections.abc.* subclass hooks check for None.

 * Mapping.__reversed__ = None.

 * One paragraph added to datamodel docs.

 * iter, reversed, and 'in' operator all raise a custom TypeError when the 
special method is None the same way as hash (but everything else will continue 
to implicitly raise the ugly TypeError).

 * Unit tests for None blocking fallback on all special methods I can think of 
(treating all the __ispam__, add the __rspam__, all inheritance except for 
__hash__, etc. as a single method each, rather than copying-pasting a 
half-dozen times).

--

___
Python tracker 

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

[issue26008] Different behaviour platform.linux_distribution() on Python2.7.11 and 3.5.1

[Eric V. Smith]

Eric V. Smith added the comment:

This is a duplicate of issue 20454.

--
nosy: +eric.smith
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> platform.linux_distribution() returns empty value on Archlinux 
and python 2.7

___
Python tracker 

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

[issue25987] collections.abc.Reversible

[Guido van Rossum]

Guido van Rossum added the comment:

Yes please. Thanks for thinking about all the edge cases here!

--
nosy: +gvanrossum

___
Python tracker 

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

[issue25988] collections.abc.Indexable

[Guido van Rossum]

Guido van Rossum added the comment:

Interesting. I just hope the name doesn't confuse people into connecting this 
with the Index type (a type of integer that can't be cast from float).

--
nosy: +gvanrossum

___
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

[Vincent Legoll]

Changes by Vincent Legoll :


--
nosy: +vincent-legoll

___
Python tracker 

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

[issue25919] http.client PUT method ignores error responses sent immediatly after headers

[Wiktor Niesiobedzki]

Wiktor Niesiobedzki added the comment:

I've checked how it behaves, when I do:
$ openssl s_client -host api.onedrive.com -port 443

The server then works like that (using curl debug log style):
> PUT /v1.0/drives/me/root:/test.file:/content HTTP/1.1
> Host: api.onedrive.com
> Content-Range: bytes 0-314572799/314572800
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Length: 314572800
> 
< HTTP/1.1 413 Request Entity Too Large
< Content-Length: 0
< Server: Microsoft-HTTPAPI/2.0
< P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"
< X-MSNSERVER: DM2304PAP130
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-ThrowSite: 7c11.e25d
< Date: Mon, 04 Jan 2016 18:44:28 GMT
> 
[...]

And I may continue sending the data.

As for 100-continue - it looks like Microsoft server is not supporting Expect: 
100-continue header, and it just waits for data, when content is shorter (like 
100 bytes).

I do not see clear indications how the client should behave in such situation 
(response received before sending complete request).

I do not understand, where you see the race condition. As we are sending in 
blocks of 8kb, if we missed the select on first block, we will catch something 
in next select. If server would close down the socket immediately, we should 
receive failure in sock.sendall() -> writing to socket that is closed for 
writing by remote party.

As I understand, right now my patch breaks uploads, when server returns HTTP 
100 response. Contrary to Issue 1346874 I'd recommend to check - if server 
returned 100 response, then continue the upload of the file or prepare error 
response for get_response(). I do not see why this behaviour should be 
implemented in code using http.client.

Status of upload should be (and it is right now) done using get_response() 
anyway, as any upload request might end in HTTP error response, so I vouch for 
empty return value - it is complaint with current interface.

I'm in progress of preparation of the test cases for such scenario using 
SocketServer, to keep it close to how network behaves, but maybe I'll manage to 
prepare testcases using FakeSocket.

--

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Guido van Rossum]

Guido van Rossum added the comment:

Agreed that improving the docs doesn't belong in this bug, but in general
if the docs aren't clear enough and only a visit to the source helps you
understand, something's wrong. Because the source may do things one way
today and be changed to do things differently tomorrow, all within the
(intended) promises of the API. But without docs we don't know what those
promises are.

--

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Andrew Barnert]

Andrew Barnert added the comment:

> IMO allowing any special method to be set to None seems to make more trouble 
> than it is worth. 

That's exactly why allowing _any_ special method to be None is a separate issue 
(#25958). Most special methods don't have any corresponding problem to the one 
with __reversed__.

> Ideally I think it would be better to require __reversed__() for reverse() to 
> work, but such a change would break compatibility.

See the -ideas thread "Deprecating the old-style sequence protocol" 
(http://article.gmane.org/gmane.comp.python.ideas/37588).

> Regarding test_enumerate.py, your class looks like this:

Please look at the two classes directly above it in the same function. The new 
Blocked exactly parallels the existing NoLen.

> I suggest either remove __getitem__() if it serves no purpose

It very definitely serves a purpose. The whole point of the new test is that 
reversed will not fall back to using __getitem__ and __len__ if __reversed__ is 
None. So __getitem__ has to be there; otherwise, we already know (from the 
NoGetItem test) that it wouldn't get called anyway.

This is exactly the same as the NoLen test, which verifies that __reversed__ 
will not fall back to __getitem__ and __len__ if one is present but not both.

> , or change it to something like this if you really want an unreversible 
> sequence:

Sure, if I wanted a real class that could be used as a sequence but could not 
be reversed. But all I want here is a toy class for testing the specific method 
lookup behavior. Again, exactly like the existing classes in the same test.

Finally, from your previous comment:

> I think the ABC documentation should clarify which methods are checked for 
> None and which aren’t. 

Looking at this a bit more: The ABC documentation doesn't even tell you that, 
e.g., Container and Hashable have subclass hooks that automatically make any 
class with __contains__ and __hash__ act like registered subclasses while, say, 
Sequence and Set don't. So, you're suggesting that we should explain where the 
hooks in some of those types differ, when we haven't even mentioned where the 
hooks exist at all. Maybe collections.abc _should_ have more detail in the 
docs, but I don't think that should be part of this bug. (Practically, I've 
always found the link to the source at the top sufficient--trying to work out 
exactly why tuple meets some ABC and some custom third-party sequence doesn't, 
which is a pretty rare case to begin with, is also pretty easy to deal with: 
you scan the source, quickly find that Sequence.register(tuple), read up on 
what it does, and realize that 
collections.abc.Sequence.register(joeschmoe.JoeSchmoeSequence) is what you 
want, and you're done.)

--

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Guido van Rossum]

Guido van Rossum added the comment:

I think I tried to address all questions in #25958.

--

___
Python tracker 

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

[issue25496] tarfile: Default value for compresslevel is not documented

[Hamza T Khan]

Hamza T Khan added the comment:

Here is trivial fix for this issue. This is my first patch and I hope that it 
gets accepted and integrated.

hamza@hamza-ub94:~/git/cpython$ grep compresslevel Lib/tarfile.py
def gzopen(cls, name, mode="r", fileobj=None, compresslevel=9, **kwargs):
fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj)
def bz2open(cls, name, mode="r", fileobj=None, compresslevel=9, **kwargs):
  compresslevel=compresslevel)
hamza@hamza-ub94:~/git/cpython$

--
hgrepos: +330
keywords: +patch
nosy: +hamzatkhan94
Added file: http://bugs.python.org/file41499/Issue25496.v1.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"

[Guido van Rossum]

Guido van Rossum added the comment:

I propose to solve the narrow problem by indeed supporting the setting of 
certain special methods to None similar to __hash__. This should be limited to 
those methods for which this adds value, e.g. where the complete absence of the 
method causes a fall-back to a different API (e.g. __getitem__+__len__ in the 
case of __reversed__) -- the None value should just block the fallback. This 
will require some changes in the ABCs that test for the presence of a given 
method (Iterable/__iter__, Container/__contains__, Reversible/__reversed__ -- 
the latter ABC should be added) and in implementations such as reversed(), 
iter() and 'in'. Maybe we should just do this for every ABC in collections.abc 
(plus Reversible) that has a __subclasshook__ that tests for the presence of 
the special method.

Oh, probably some more, like Iterator/__next__, Sized/__len__ and 
Callable/__call__. But for those there isn't a fallback in the corresponding 
bytecode, so I'm only +0 for those -- it doesn't seem to harm anything to be 
consistent with those for which it does matter, but it doesn't cost much 
either, and the consistency is slightly useful -- it provides a pattern to 
follow for future ABCs.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Phil Thompson]

Phil Thompson added the comment:

At the moment my importer does the same as zipimport and gets added to 
sys.path_hooks rather than sys.meta_path.

While waiting for the PEP, how about a table of (externally modifiable) 
importer installers that is worked through where _PyImportZip_Init() is 
currently called? By default _PyImportZip_Init() will be the only entry.

--

___
Python tracker 

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

[issue25998] doctest terminates when accessing __wrapped__ raises an error

[R. David Murray]

R. David Murray added the comment:

Gah. Having hit send I of course had second thoughts.  doctest is suppose to 
*report* bugs, so there *is* a doctest bug here: it should be capturing that 
and probably other errors and reporting them, instead of just producing a 
traceback, I think.

--
resolution: third party -> 
stage: resolved -> needs patch
status: closed -> open
title: doctest crashes when accessing __wrapped__ fails other than 
AttributeError -> doctest terminates when accessing __wrapped__ raises an error
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

[issue25998] doctest crashes when accessing __wrapped__ fails other than AttributeError

[R. David Murray]

R. David Murray added the comment:

No, I don't think doctest should be made robust against RuntimeErrors.  
doctest's purpose is to check for bugs, and IMO this is a bug in flask.  In 
particular, it is not doctest that flask is not cooperating with, it is 
hasattr.  It used to be that hasattr would mask errors raised, and this caused 
a number of both debugging and production problems, to the point where hasattr 
was not considered safe to use.  But it eventually got fixed: 
http://www.gossamer-threads.com/lists/python/dev/856859

--
nosy: +r.david.murray
resolution:  -> third party
stage:  -> 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

[issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer

[Ethan Furman]

Changes by Ethan Furman :


--
nosy: +ethan.furman

___
Python tracker 

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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Brett Cannon]

Brett Cannon added the comment:

What Phil is after is a hook at the C level that will allow him to modify the 
sys module to add something to sys.meta_path to remove PathEntryFinder and put 
in his own importer (assuming he isn't simply freezing everything).

And yes, you should be able to run the stdlib from a zipfile, but the issue 
here is all the stuff Python imports as part of startup before the first bit of 
user Python code is executed, e.g. the encodings module. Since zipimport is 
added by importlib it gets special treatment  to be usable ASAP. Since Phil 
wants to completely skew standard import mechanisms this does require a C hook.

What this all means is that Phil really needs 
https://www.python.org/dev/peps/pep-0432/ to happen so that he can easily get 
his hook point added into the startup sequence.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue17633] zipimport's handling of namespace packages is incorrect

[Mike Romberg]

Mike Romberg added the comment:

I have expanded on the issue17633-2 patch to fix an issue with the enumerated 
value returned by find_loader().  The patch (issue17633-3.diff) is against 
3.5.1.

  I have also added more test cases that cover spreading a namespace package 
across two zip files and between a zip file and a filesystem.  The expanded 
tests cover the iterable __path__ member of a namespace package.

  No new failures in 'make test'  (gdb and ssl were broken with in 3.5.1 before 
this patch).

  The expanded test cases should continue to be relevant even if zipimport is 
rewritten.

--
nosy: +romberg
Added file: http://bugs.python.org/file41498/issue17633-3.diff

___
Python tracker 

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

[issue26009] HTMLParser lacking a few features to reconstruct input exactly

[Jason Sachs]

Jason Sachs added the comment:

sample file test1.html attached.

When running test2.py on it, the output is identical except for two things:

test1.html  contains 
test1b.html contains 

test1.html contains end tags that are capitalized e.g.  or have spaces 
test1b.html contains end tags that are canonicalized to lowercase and without 
spaces e.g.  and 

--
Added file: http://bugs.python.org/file41497/test1.html

___
Python tracker 

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

[issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer

[Brett Cannon]

Brett Cannon added the comment:

A warning directive at the start of http.server about needing to trust users 
would work?

--
nosy: +brett.cannon

___
Python tracker 

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

[issue26009] HTMLParser lacking a few features to reconstruct input exactly

[Jason Sachs]

New submission from Jason Sachs:

The HTMLParser class (https://docs.python.org/2/library/htmlparser.html) is 
lacking a few features to reconstruct input exactly. For the most part it can 
do this, but I found two items where it falls short (there may be others):

- There is a get_starttag_text() method but no get_endtag_text() method, which 
is necessary if the end tag is not in canonical form, e.g. instead of  it 
is  or 

- The effect of the parse_bogus_comment() internal method is to call 
handle_comment(), so content like  cannot be distinguished by 
subclasses of HTMLParser from actual comments 

Suggested changes:

- Add a get_endtag_text() method to return the exact endtag text
- change parse_bogus_comment to call self.handle_bogus_comment(), and define 
self.handle_bogus_comment() to call self.handle_comment(). This way it is 
backwards-compatible with existing behavior, but subclasses can redefine 
self.handle_bogus_comment() to do what they want.

--
messages: 257472
nosy: jason_s
priority: normal
severity: normal
status: open
title: HTMLParser lacking a few features to reconstruct input exactly
type: behavior
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

[issue26009] HTMLParser lacking a few features to reconstruct input exactly

[Jason Sachs]

Jason Sachs added the comment:

sample file attached containing VerbatimParser

--
Added file: http://bugs.python.org/file41496/test2.py

___
Python tracker 

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

[issue26008] Different behaviour platform.linux_distribution() on Python2.7 and 3.6

[Antonio Álvarez]

New submission from Antonio Álvarez:

Hi! I have a doubt, is this behaviour in Python2.7.11 usual, or is it a bug?

>>> import platform
>>> platform.linux_distribution()
('', '', '')

In Python3.5.1 I get

>>> import platform
>>> platform.linux_distribution()
('arch', 'Arch', 'Linux')

I work with Archlinux x86_64 with lsb-release installed. Thanks!

--
components: Extension Modules
messages: 257471
nosy: analca3
priority: normal
severity: normal
status: open
title: Different behaviour platform.linux_distribution() on Python2.7 and 3.6
type: behavior
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

[issue26008] Different behaviour platform.linux_distribution() on Python2.7.11 and 3.5.1

[Antonio Álvarez]

Changes by Antonio Álvarez :


--
title: Different behaviour platform.linux_distribution() on Python2.7 and 3.6 
-> Different behaviour platform.linux_distribution() on Python2.7.11 and 3.5.1

___
Python tracker 

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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Phil Thompson]

Phil Thompson added the comment:

Yes, preventing the filesystem being used for imports would be another way of 
expressing the issue.

Regarding the title I specifically didn't want to suggest a solution as I'm not 
expert enough to know what the best solution might be.

If, as Paul implies, it should be possible to run the standard library from a 
zipfile then it suggests that this should actually be a bug report.

--

___
Python tracker 

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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

So the use case is that you want to explicitly prevent the file system from 
being used for imports ?

You might want to look at how eGenix PyRun works, since this does embed the 
Python stdlib into the executable (including the encodings package). While it 
does allow imports from the file system, it only looks there for things it 
cannot find embedded in the binary.

PS: I'd suggest to make the issue title more specific to what you are actually 
after, which seems to be a way to install importers from C at a very early 
stage during initialization.

--
nosy: +lemburg

___
Python tracker 

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

[issue17006] Add advice on best practices for hashing secrets

[Ramchandra Apte]

Ramchandra Apte added the comment:

It is good to add warnings; if they are ignored it is little worse than the
status quo.

On 1 January 2016 at 08:54, Ezio Melotti  wrote:

>
> Ezio Melotti added the comment:
>
> > People are going to skip warning boxes if they occur too often.
>
> I'm not sure I agree.  This would be true if they were abused for trivial
> things ("Warnings: using .pop() on a empty list will return an
> IndexError!"), but I don't think they are.
>
> I think warnings are ignored only by people that are already familiar with
> the module and its limitation/issues, and that know what they are doing.
> If the warning is not evident, people are going to miss it [0].
>
> If warnings are used correctly, people will spot them easily and read them
> (or ignore them if they already know what they are warning against).
>
> [0]: I know I missed it in e.g. https://api.jquery.com/die/ -- the
> function is deprecated, but (currently) this is only written in the top
> right corner and in small in the category at the top -- two places that are
> easily overlooked.  https://api.jquery.com/toggle-event/ on the other
> hand has a clearly visible yellow box at the top that immediately says that
> the method is deprecated.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue25998] doctest crashes when accessing __wrapped__ fails other than AttributeError

[Lasse Schuirmann]

Lasse Schuirmann added the comment:

Sorry for giving it the wrong category.

I personally think both projects should solve this. IMO it would be nice if 
doctest is robust against modules that for some reason (be they ill designed or 
not; I guess if you search a lot you find a project that needs to raise a 
custom exception when accessing `__wrapped__`). At the same time I do think the 
Flask request object could handle this better but lack the ability to explain 
that to them with substantial reasoning.

The problem is that both of you don't want to solve this problem at their side, 
@steven.daprano, would you mind speaking with the Flask people directly? I'm 
not affiliated to them.

--

___
Python tracker 

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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Phil Thompson]

Phil Thompson added the comment:

The problem is the import of the encodings module in _PyCodecRegistry_Init().

--

___
Python tracker 

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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Paul Moore]

Paul Moore added the comment:

Why is it too late to install a new importer to sys.path_hooks when zipimport 
is installed? As far as I am aware, running the stdlib from a zipfile works 
fine, which seems to be equivalent to your use case.

--
nosy: +paul.moore

___
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

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Removed file: http://bugs.python.org/file41491/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

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added 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

[issue26007] Request for Support for Embedding the Standard Library in an Executable

[Phil Thompson]

New submission from Phil Thompson:

The use case is a packaging tool that can create a single executable for a 
Python application. Like similar tools it embeds frozen Python code (including 
the standard library) and is linked (often statically) against the interpreter 
library.

Executables are usually configured so that they cannot import packages from the 
filesystem. They can only import packages embedded in the executable. This is 
done directly, ie. the package is not written out to the filesystem and 
imported from there. This is done by a specially written importer.

The importer is installed by adding it to sys.path_hooks. However this must be 
done early on in the bootstrap process so that the parts of the standard 
library that are implemented as Python packages can be found by the installer. 
For example, the point at which the zipimport importer is added to 
sys.path_hooks is too late.

Currently a modified version of bootstrap_external.py is embedded in the 
executable which updates sys.path_hooks at the end of the _install() function.

What I would like is some way to avoid having to modify bootstrap_external.py 
to install a new importer sufficiently early in the bootstrap process to allow 
it to import the standard library.

--
components: Interpreter Core
messages: 257464
nosy: philthompson10
priority: normal
severity: normal
status: open
title: Request for Support for Embedding the Standard Library in an Executable
type: enhancement
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

[issue25702] Link Time Optimizations support for GCC and CLANG

[Alecsandru Patrascu]

Changes by Alecsandru Patrascu :


Added file: http://bugs.python.org/file41494/lto-cpython3-v03.patch

___
Python tracker 

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

[issue25702] Link Time Optimizations support for GCC and CLANG

[Alecsandru Patrascu]

Alecsandru Patrascu added the comment:

Hello, I've added an updated set of patches (v03) for the current CPython2 and 
CPython3 codebase. Also made some small changes to reduce the number of places 
where the flags are set.

--
Added file: http://bugs.python.org/file41493/lto-cpython2-v03.patch

___
Python tracker 

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

[issue26006] 32 bits python ctypes creates 64 bits process from 32 bits executable

[Artur Korobeynyk]

Artur Korobeynyk added the comment:

the Wow64Process output parameter is true for a 32-bit process. WOW64 is short 
for Win32 running on Win64 (i.e. the environment used to run 32-bit programs in 
64-bit Windows). Even a 32-bit WOW64 process has some 64-bit modules, such as 
ntdll.dll, wow64.dll, wow64win.dll, and wow64cpu.dll

--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue26006] 32 bits python ctypes creates 64 bits process from 32 bits executable

[Artur Korobeynyk]

New submission from Artur Korobeynyk:

Hi,

I have a 32 bits python on 64 bits Windows and 32 bits executable (compiled 
from native C).
When I do kernel32.CreateProcessA(path_to_exe, ...) python creates a process 
which is 64 bit (ctypes IsWow64Process returns true).
I expect it to be 32 as well. Am I wrong or that is a bug?

I attached testprog.exe but it requires testdll.dll
The sources of testprog.c:

#include 
#include 

int main()
{

Sleep(15000);
printf("%d", testSum(5,10));
return 0;
}

testdll.c

#include 

__declspec(dllexport) int __cdecl testSum(int a, int b)
{
return(a+b);
}

compiled as:
/usr/bin/i686-pc-mingw32-gcc.exe -c testdll.c
/usr/bin/i686-pc-mingw32-gcc.exe --shared -o testdll.dll testdll.o
/usr/bin/i686-pc-mingw32-gcc.exe -o testprog testprog.c -L. -ltestdll

Process creation:
if kernel32.CreateProcessA(path_to_exe,
   None,
   None,
   None,
   None,
   creation_flags,
   None,
   None,
   byref(startupinfo),
   byref(process_information))

--
components: ctypes
files: testprog.exe
messages: 257461
nosy: Artur Korobeynyk
priority: normal
severity: normal
status: open
title: 32 bits python ctypes creates 64 bits process from 32 bits executable
versions: Python 2.7
Added file: http://bugs.python.org/file41492/testprog.exe

___
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

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Proposed patch implements getting, deleting and setting slices in deque.

Getting a slice returns a list, but this can be changed if needed.

--
assignee:  -> rhettinger
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file41491/deque_slices.patch

___
Python tracker 

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

[issue24313] json fails to serialise numpy.int64

[Thomas Arildsen]

Thomas Arildsen added the comment:

Thanks for the clarification.

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

[issue24036] GB2312 codec is using a wrong covert table

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

Thanks, Ma Lin.

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

[issue24036] GB2312 codec is using a wrong covert table

[Ma Lin]

Ma Lin added the comment:

I agree with you, "won't fix".

--

___
Python tracker 

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

[issue25596] regular files handled as directories in the glob module

[Xavier de Gaye]

Xavier de Gaye added the comment:

> and since _iterdir() results are always accumulated in a list

Right, I failed to note that point. And so, since the file descriptor opened by 
os.scandir() is closed within each call to recursive _rlistdir(), then my other 
comment about EMFILE does not stand as well.

--

___
Python tracker 

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

[issue24313] json fails to serialise numpy.int64

[Nathaniel Smith]

Nathaniel Smith added the comment:

Nothing's changed in python 2.7. Basically: (a) no numpy ints have ever 
serialized in py3. (b) in py2, either np.int32 *xor* np.int64 will serialize 
correctly, and which one it is depends on sizeof(long) in the C compiler used 
to build Python. (This follows from the fact that in py2, the Python 'int' type 
is always the same size as C 'long'.)

So the end result is: on OS X and Linux, 32-bit Pythons can JSON-serialize 
np.int32 objects, and 64-bit Pythons can JSON-serialize np.int64 objects, 
because 64-bit OS X and Linux is ILP64. On Windows, both 32- and 64-bit Pythons 
can JSON-serialize np.int32 objects, and can't serialize np.int64 objects, 
because 64-bit Windows is LLP64.

--

___
Python tracker 

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

[issue24036] GB2312 codec is using a wrong covert table

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

I think we can close this issue as "won't fix".

It's a bug, but one which is present in a lot of other systems as well, so we'd 
potentially make it impossible to write GB2312 data which is supposed to be 
read back by these other systems.

Ma Lin: Do you agree ?

--

___
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

[koobs]

koobs added the comment:

Can't / Shouldn't these be mocked?

--

___
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

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 04.01.2016 08:43, Martin Panter wrote:
> 
> In the meantime, this patch changes the tests to use the new DST root 
> certificate. This seems to be the minimum to make the tests pass again, but 
> someone else should probably review it because I’m not too experienced with 
> SSL certificate stuff.

Thanks. I still think that we should use a more stable
resource for this other than svn.python.org, e.g. the
https://www.pythontest.net/ setup which was created specifically
for stdlib tests and which can more easily be adapted to
fit the needs of the tests than a public resource which is meant
for other purposes.

The local server idea may also work, but would have to run on
a non-privileged port.

--

___
Python tracker 

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

[issue24313] json fails to serialise numpy.int64

[Thomas Arildsen]

Thomas Arildsen added the comment:

Is there any possibility that json could implement special handling of NumPy 
types? This "lack of a feature" seems to have propagated back into Python 2.7 
now in some recent update...

--

___
Python tracker 

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

[issue25433] whitespace in strip()/lstrip()/rstrip()

[Dimitri Papadopoulos Orfanos]

Dimitri Papadopoulos Orfanos added the comment:

In Python 3 the situation is similar:
* The Py_UNICODE_ISSPACE macro is used internally to define str.isspace() and 
wherever Python needs to detect "whitespace" characters in strings.
* There is an equivalent function Py_ISSPACE for bytes/bytearray.
* The bytearray.strip() implementation for bytearray relies on hardcoded ASCII 
whitespaces instead of Py_ISSPACE.
* string.whitespace is a list of "ASCII whitespace characters" carved in stone. 
As far as I can see string.whitespace is defined but not used anywhere in 
Python source code.

Therefore I suggest the documentation of Python 3 points to str.isspace() 
wherever the term "whitespace" is used in any documentation related to strings 
- including this specific case of strip()/lstrip()/rstrip().

--

___
Python tracker 

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

[issue25433] whitespace in strip()/lstrip()/rstrip()

[Dimitri Papadopoulos Orfanos]

Dimitri Papadopoulos Orfanos added the comment:

In Python 2, as far as I can understand, string.whitespace and str.isspace() 
are different:
* str.isspace() is built upon the C isspace() function and is therefore 
locale-dependant. Python heavily relies on isspace() to detect "whitespace" 
characters.
* string.whitespace is a list of "ASCII whitespace characters" carved in stone. 
As far as I can see string.whitespace is defined but not used anywhere in 
Python source code.

See source code:
* Modules/stringobject.c around line 3319:
  [...]
  string_isspace(PyStringObject *self)
  {
  [...]
  e = p + PyString_GET_SIZE(self);
  for (; p < e; p++) {
  if (!isspace(*p))
  return PyBool_FromLong(0);
  }
  return PyBool_FromLong(1);
  [...]
* Lib/string.py near line 23:
  whitespace = ' \t\n\r\v\f'

Functions strip()/lstrip()/rstrip() use str.isspace() and have nothing to do 
with string.whitespace:

* Modules/stringobject.c around line 1861:
[...]
do_strip(PyStringObject *self, int striptype)
{
[...]
i = 0;
if (striptype != RIGHTSTRIP) {
while (i < len && isspace(Py_CHARMASK(s[i]))) {
i++;
}
}
[...]

Therefore I suggest the documentation of Python 2.7 points to str.isspace() 
wherever the term "whitespace" is used in the documentation - including this 
specific case of strip()/lstrip()/rstrip().

--

___
Python tracker 

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

[issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer

[STINNER Victor]

STINNER Victor added the comment:

"I think a server robust against that sort of stuff would be out of scope for 
SimpleHTTPServer."

We can probably enhance SimpleHTTPServer but I agree that the server should 
remain simple. Maybe we should be more explicit in the documentation that the 
server requires to trust users?

--
nosy: +haypo

___
Python tracker 

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

[issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer

[Martin Panter]

Martin Panter added the comment:

I expect the server _is_ waiting for the end of the headers before handling the 
response. The problem is if you do not send the blank line, the server cannot 
know if you have ended the headers or if there are more to come.

Perhaps you could set a socket timeout in the server. But an attacker could 
still send little bits of the header very slowly (called Slow Loris attack or 
something I think). I think a server robust against that sort of stuff would be 
out of scope for SimpleHTTPServer.

--
nosy: +martin.panter

___
Python tracker 

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

[issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer

[Richard Clifford]

New submission from Richard Clifford:

The issue comes when there is a malformed HTTP request not ending in a new 
line, it causes the server to hang, not timeout and causes a DoS.

The request that I sent to the server was as follows:
const char *headers = "GET / HTTP/1.1\r\nHost: localhost:8000\r\n";

Which should have been:
const char *headers = "GET / HTTP/1.1\r\nHost: localhost:8000\r\n\r\n";

This causes a the application to await the second set of new-line sequences and 
hang until they are received which prevents any further connections from being 
made. 

I have just tested this against the latest versions of the library and I can 
supply a proof of concept code if that would be useful - just let me know.

A recommended fix would be to ensure that all HTTP requests are received in 
full and in the correct manor prior to being parsed.

--
components: Extension Modules
files: basehttpdos.c
messages: 257446
nosy: Richard Clifford
priority: normal
severity: normal
status: open
title: Denial of Service in SimpleHTTPServer and BaseHTTPServer
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41490/basehttpdos.c

___
Python tracker 

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

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

[Debashish Maity]

New submission from Debashish Maity:

Not able to install "lifetimes" package using pip script.
Need urgent help.

Followed the following links for help, but still no success
http://blog.ionelmc.ro/2014/12/21/compiling-python-extensions-on-windows/
http://stackoverflow.com/questions/26473854/python-pip-has-issues-with-path-for-ms-visual-studio-2010-express-for-64-bit-ins/26513378#26513378

--
components: Windows
files: log.txt
messages: 257445
nosy: dudestc, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pip install lifetimes - throwing error and unable to install packages
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file41489/log.txt

___
Python tracker 

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

[issue20397] distutils --record option does not validate existence of byte-compiled files

[koobs]

koobs added the comment:

setuptools and therefore pip are also affected by this

--

___
Python tracker 

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

[issue20397] distutils --record option does not validate existence of byte-compiled files

[koobs]

Changes by koobs :


--
keywords: +easy
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