[issue21872] LZMA library sometimes fails to decompress a file

[Akira Li]

Akira Li added the comment:

If lzma._BUFFER_SIZE is less than 2048 then all example files are
decompressed successfully (at least lzma module produces the same
results as xz utility)

--
Added file: http://bugs.python.org/file37241/decompress-example-files.py

___
Python tracker 

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

[issue21872] LZMA library sometimes fails to decompress a file

[Akira Li]

Changes by Akira Li <4kir4...@gmail.com>:


Removed file: http://bugs.python.org/file37240/decompress-example-files.py

___
Python tracker 

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

[issue22894] unittest.TestCase.subTest causes all subsequent tests to be skipped in failfast mode

[Michael Foord]

Michael Foord added the comment:

Looks good, thanks for the quick response.

--

___
Python tracker 

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

[issue22910] test_pydoc test_synopsis_sourceless is a flaky test

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
assignee: gregory.p.smith -> 

___
Python tracker 

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

[issue22910] test_pydoc test_synopsis_sourceless is a flaky test

[Gregory P. Smith]

Gregory P. Smith added the comment:

I suspect flakiness is due to parallel test execution.  Is some other test 
possibly executing at the same time removing __pycache__ directories or .pyc 
files to recreate them (test_compileall?)?  If the test were adjusted to point 
to a .py file of its own that it generates in a temporary directory that would 
avoid that.

--

___
Python tracker 

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

[issue20123] pydoc.synopsis fails to load binary modules

[Gregory P. Smith]

Gregory P. Smith added the comment:

fyi - tracking the new issue koobs reported in http://bugs.python.org/issue22910

--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional

[Bernard Spil]

Bernard Spil added the comment:

Hi, 

I think this can be found in LibreSSL's opensslv.h 
An ifdef LIBRESSL_VERSION_NUMBER should work

See 
https://github.com/libressl-portable/openbsd/blob/master/src/lib/libssl/src/crypto/opensslv.h

_ssl.c includes crypto.h which in turn includes opensslv.h so checking for 
LIBRESSL_VERSION_NUMBER should provide the correct check.

Attached patch does this in C whereas it should be checked for in configure and 
disabled with a HAS_RAND_egd
Have not figured out how to do this conditionally in Lib/ssl.py yet

--
Added file: http://bugs.python.org/file37242/patch-Modules__ssl.c

___
Python tracker 

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

[issue22908] ZipExtFile in zipfile can be seekable

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Actually TarFile already works with non-seekable streams. Use TarFile.open() 
with mode='r|*' or like.

On other hand I'm not against the make non-compressed ZipExtFile seekable. It 
can be helpful in case when ZIP file is used just as a container for other 
files.

--
assignee:  -> serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.5 -Python 3.4

___
Python tracker 

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

[issue14099] ZipFile.open() should not reopen the underlying file

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I hesitate about applying the patch to maintained releases. On one hand, 
besides interface (even non-documented details) left the same, the patch 
changes interiors too much for ordinal bug. I don't see how it can break 
something, but this doesn't guarantee that changes don't have unexpected effect.

On other hand, this bug can be considered as security-related issue. Malicious 
local attacker could replace ZIP file between its open and read from it or 
between two reads, if he has write access to the directory containing ZIP file 
or there are symplinks under his control in ZIP file path. The danger of this 
may exceed hypothetical negative consequences of the applying of the patch.

I appeal the matter to release managers. Should we apply this patch (the risk 
is pretty small) to 2.7 and 3.4?

--
nosy: +benjamin.peterson, larry

___
Python tracker 

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

[issue22687] horrible performance of textwrap.wrap() with a long word

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

So what the patch (with mitigated tests) is more preferable?

--

___
Python tracker 

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

[issue14099] ZipFile.open() should not reopen the underlying file

[David Wilson]

David Wilson added the comment:

While in spirit this is a bug fix, it's reasonably complex and affects a 
popular module -- I'm not sure it should be applied to 2.x, and probably not in 
a minor release of 3.x either. Would it make sense to include as part of 3.5?

(That said, I'd love to see this fixed in 2.x ;))

--

___
Python tracker 

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

[issue19720] suppress context for some exceptions in importlib?

[Brett Cannon]

Brett Cannon added the comment:

LGTM

--
assignee: brett.cannon -> serhiy.storchaka
stage: patch review -> commit review

___
Python tracker 

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

[issue22834] Unexpected FileNotFoundError when current directory is removed

[Brett Cannon]

Brett Cannon added the comment:

I have a patch to silence the exception and I'm running the test suite now.

I'm planning to keep this to a 3.5 fix and not changing the semantics in Python 
3.4 as the fix is a little different from the standard "directory in sys.path 
is invalid" since '' is dynamic and I can see someone relying on the current 
exception bubbling out somehow and not caching the dead directory in 
sys.path_importer_cache.

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

[issue22906] PEP 479: Change StopIteration handling inside generators

[Marc Schlaich]

Marc Schlaich added the comment:

AFAIS this would break all existing code for yield-based coroutine schedulers 
(Tornado, Twisted, Trollius, monocle, ...) when a coroutine is exited with 
`raise StopIteration` in client code. 

And this seems like a lot, a quick GitHub code search gives various examples, 
e.g.

- 
https://github.com/circus-tent/circus-web/blob/3b76c83d1eb984a78ed69a9abcb13054cde78f89/circusweb/circushttpd.py#L170
- 
https://github.com/kzahel/falcon-api/blob/5c62454db971bc99c52694cf2ce0613fb1504d80/python/falcon_api/session.py#L159
- 
https://github.com/peterhajas/Genesis/blob/2f1a03c38934b892ee6bb04e07e867bf463b7ae5/servers/genesis/clients.py#L24

--
nosy: +schlamar

___
Python tracker 

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

[issue22834] Unexpected FileNotFoundError when current directory is removed

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8558fff73032 by Brett Cannon in branch 'default':
Issue #22834: Have import suppress FileNotFoundError when the current
https://hg.python.org/cpython/rev/8558fff73032

--
nosy: +python-dev

___
Python tracker 

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

[issue22834] Unexpected FileNotFoundError when current directory is removed

[Brett Cannon]

Brett Cannon added the comment:

Along with fixing this I also updated the import reference to mention how the 
current working directory is handled.

Thanks to Martin for the report and everyone for their input!

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.4

___
Python tracker 

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

[issue22906] PEP 479: Change StopIteration handling inside generators

[Chris Angelico]

Chris Angelico added the comment:

Marc, are those all cases where the "raise StopIteration" is actually inside a 
generator? If so, it can be trivially replaced with "return". Yes, it'll break 
that way of spelling it, but it's a completely mechanical transformation, and 
making the change won't break your code for previous versions of Python. 
Personally, I would recommend using "return" there anyway, regardless of this 
proposal.

--

___
Python tracker 

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

[issue22906] PEP 479: Change StopIteration handling inside generators

[Marc Schlaich]

Marc Schlaich added the comment:

Yes, all yield-based coroutines are generators. I know that there is a backward 
compatible upgrade path, but this might have a huge impact on existing code.

Interestingly, I didn't know before researching this PEP that you can actually 
use `return` without arguments in generators before Python 3.3 (even in 2.3) 
and I have worked a lot with coroutines/generators.

So I'm not even against this proposal and using `return` instead of `raise 
StopIteration` seems the right way to exit a generator/coroutine, but there 
could be lots of affected users...

--

___
Python tracker 

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

[issue22906] PEP 479: Change StopIteration handling inside generators

[Chris Angelico]

Chris Angelico added the comment:

Yep, the question is whether any of the "raise StopIteration" lines are 
actually non-local flow control. If they're local, then it's easy: mechanical 
replacement with "return" and it becomes compatible with all versions (unless 
it has a value attached to it, as "return x" doesn't work in Py2). But if 
they're non-local, some refactoring will need to be done.

In any case, my line of argument is: A generator function is not an iterator's 
__next__ method, ergo iterator protocol does not apply. Use of StopIteration is 
a hack that happens to work because of how generator functions are implemented 
(a thin wrapper around an iterator), but it's not part of the *concept* of a 
generator function.

--

___
Python tracker 

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

[issue22394] Update documentation building to use venv and pip

[Brett Cannon]

Brett Cannon added the comment:

I'm going to at least update the Makefile to have a ``make venv`` that will do 
the steps necessary to create a venv and then check out the necessary tools. It 
should also be set up so that running the command with a pre-existing venv will 
update it. This should all lead to commands like ``make html 
PYTHON=venv/bin/python3`` to work.

--
assignee: docs@python -> brett.cannon

___
Python tracker 

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

[issue22906] PEP 479: Change StopIteration handling inside generators

[Guido van Rossum]

Guido van Rossum added the comment:

If all examples were just using "raise StopIteration" instead of "return"
in a generator I would be very happy. Such code can be trivially fixed by
using "return" and the __future__ import will help the eventual transition.

It's sad that apparently this use of return hasn't been better advertised
-- it has existed since generators were first introduced.

On Fri, Nov 21, 2014 at 9:44 AM, Chris Angelico 
wrote:

>
> Chris Angelico added the comment:
>
> Yep, the question is whether any of the "raise StopIteration" lines are
> actually non-local flow control. If they're local, then it's easy:
> mechanical replacement with "return" and it becomes compatible with all
> versions (unless it has a value attached to it, as "return x" doesn't work
> in Py2). But if they're non-local, some refactoring will need to be done.
>
> In any case, my line of argument is: A generator function is not an
> iterator's __next__ method, ergo iterator protocol does not apply. Use of
> StopIteration is a hack that happens to work because of how generator
> functions are implemented (a thin wrapper around an iterator), but it's not
> part of the *concept* of a generator function.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue22906] PEP 479: Change StopIteration handling inside generators

[Chris Angelico]

Chris Angelico added the comment:

Sadly, I don't know of a way to check if that's the case, other than by 
manually going through and eyeballing the code - if there's "raise 
StopIteration", see if there's also "yield" in the same function. The three 
cited examples are (I checked those straight away), but frankly, I am not 
volunteering to go manually through all of github in search of examples :|

--

___
Python tracker 

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

[issue22906] PEP 479: Change StopIteration handling inside generators

[R. David Murray]

Changes by R. David Murray :


--
nosy: +r.david.murray

___
Python tracker 

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

[issue22906] PEP 479: Change StopIteration handling inside generators

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I suggest to apply right now those changes which are compatible with current 
behavior and don't make code more cumbersome. E.g.

-while True:
-yield next(line_pair_iterator)
+yield from line_pair_iterator

and

-raise StopIteration
+return

To me these changes make code even better and are worth to be applied even if 
PEP 479 will be rejected.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue19720] suppress context for some exceptions in importlib?

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2de3c659a979 by Serhiy Storchaka in branch 'default':
Issue #19720: Suppressed context for some exceptions in importlib.
https://hg.python.org/cpython/rev/2de3c659a979

--
nosy: +python-dev

___
Python tracker 

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

[issue22911] Segfault on recursive itertools.chain.from_iterable

[Ian Kelly]

New submission from Ian Kelly:

I expect this should result in a recursion depth exceeded error, not a 
segmentation fault.

$ cat test.py
import itertools

l = []
it = itertools.chain.from_iterable(l)
l.append(it)
next(it)
$ python3 test.py
Segmentation fault (core dumped)

--
components: Library (Lib)
messages: 231489
nosy: ikelly
priority: normal
severity: normal
status: open
title: Segfault on recursive itertools.chain.from_iterable
versions: Python 3.4

___
Python tracker 

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

[issue14010] deeply nested filter segfaults

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See issue22911 for another instance of this in chain.from_iterable().

--

___
Python tracker 

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

[issue22911] Segfault on recursive itertools.chain.from_iterable

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This is a duplicate of issue14010.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> deeply nested filter segfaults

___
Python tracker 

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

[issue22912] urlretreive locks up in 2.7.8

[Taylor Marks]

New submission from Taylor Marks:

The following code causes Python 2.7.8 to lockup for ten minutes, then crash, 
in both Windows 7 and OS X:

from urllib import urlretrieve
urlretrieve('http://chromedriver.storage.googleapis.com/2.12/chromedriver_win32.zip',
 'chromedriver_win32.zip')

Here's a thread on StackOverflow where I originally posted about this bug, 
assuming it was an issue in my code, before other people let me know that the 
problem wasn't my code, but with Python 2.7.8, on both Windows 7 and OS X, and 
that in older versions of Python, such as 2.7.6, the code works fine.

http://stackoverflow.com/questions/27025998/urllib-urlretreive-completely-locks-up-python

--
components: Library (Lib)
messages: 231492
nosy: TaylorSMarks
priority: normal
severity: normal
status: open
title: urlretreive locks up in 2.7.8
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

[issue19720] suppress context for some exceptions in importlib?

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8f77f7bb46c7 by Serhiy Storchaka in branch 'default':
Issue #19720: Suppressed context for some exceptions in importlib.
https://hg.python.org/cpython/rev/8f77f7bb46c7

--

___
Python tracker 

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

[issue19720] suppress context for some exceptions in importlib?

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue17293] uuid.getnode() MAC address on AIX

[Roundup Robot]

Roundup Robot added the comment:

New changeset 301d62ef5c0b by Serhiy Storchaka in branch '2.7':
Issue #17293: socket.gethostbyname() can raise an exception of FreeBSD.
https://hg.python.org/cpython/rev/301d62ef5c0b

New changeset 97ceab0bd6f8 by Serhiy Storchaka in branch '3.4':
Issue #17293: socket.gethostbyname() can raise an exception of FreeBSD.
https://hg.python.org/cpython/rev/97ceab0bd6f8

--

___
Python tracker 

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

[issue22913] Rewrite of Python 2/3 porting HOWTO

[Brett Cannon]

Changes by Brett Cannon :


--
resolution:  -> duplicate
status: open -> closed
superseder:  -> Rewrite of Python 2/3 porting HOWTO

___
Python tracker 

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

[issue22914] Rewrite of Python 2/3 porting HOWTO

[Brett Cannon]

New submission from Brett Cannon:

This is a rewrite of the Python 2/3 porting HOWTO to describe how to make code 
be compatible with both Python 2 & 3. To see it rendered for easier reading, 
see https://gist.github.com/brettcannon/91ff264ae549315706f6

--
assignee: brett.cannon
components: Documentation
files: pyporting.diff
keywords: patch
messages: 231496
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Rewrite of Python 2/3 porting HOWTO
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37244/pyporting.diff

___
Python tracker 

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

[issue19720] suppress context for some exceptions in importlib?

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Sorry, 8f77f7bb46c7 is related to issue17293, not this issue. I have copied 
wrong commit message from clipboard.

--

___
Python tracker 

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

[issue22913] Rewrite of Python 2/3 porting HOWTO

[Brett Cannon]

New submission from Brett Cannon:

This is a rewrite of the Python 2/3 porting HOWTO to describe how to make code 
be compatible with both Python 2 & 3. To see it rendered for easier reading, 
see https://gist.github.com/brettcannon/91ff264ae549315706f6

--
assignee: brett.cannon
components: Documentation
files: pyporting.diff
keywords: patch
messages: 231495
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Rewrite of Python 2/3 porting HOWTO
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37243/pyporting.diff

___
Python tracker 

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

[issue22914] Rewrite of Python 2/3 porting HOWTO

[Berker Peksag]

Changes by Berker Peksag :


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

[issue22914] Rewrite of Python 2/3 porting HOWTO

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue22914] Rewrite of Python 2/3 porting HOWTO

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Why you have removed many sections: about subclassing from object, using io 
classes, comparison of bytes with unicode objects, the use of warnings and -b 
and -3 options and other subtle details?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue22912] urlretreive locks up in 2.7.8

[Ned Deily]

Ned Deily added the comment:

Sorry, I'm unable to reproduce the problem using various systems and various 
version of Python 2.7.  And, as I read the StackOverflow comments, it appears 
that no one else was able to reproduce the problem, either.  To investigate 
further, we would need more information, including a copy of the exception 
traceback or other info when the failure occurs.

--
nosy: +ned.deily

___
Python tracker 

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

[issue19361] Specialize exceptions thrown by JSON parser

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

While we here may be change error messages?

The only error which contains end position is "Extra data". And it doesn't look 
clean to me why end position should be mentioned at all (it is always len(data) 
here). I suggest to drop it, this will make error message cleaner and 
JSONDecodeError simpler.

May be mention line and column in error message only if JSON data is multiline? 
Most machine generated data has one line only. Instead of "Expecting ',' 
delimiter: line 1 column 123 (char 124)" I suggest "Expecting ',' delimiter at 
position 124". Same as in re.error.

--

___
Python tracker 

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

[issue10510] distutils upload/register should use CRLF in HTTP requests

[Éric Araujo]

Éric Araujo added the comment:

Thanks bitdancer for applying this.

FTR I just stumbled on code extracted from chishop that shows Django had issues 
with the non-CRLF requests sent by distutils: 
https://github.com/disqus/djangopypi/blob/master/djangopypi/http.py#L19

--

___
Python tracker 

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

[issue17311] use distutils terminology in "PyPI package display" section

[Éric Araujo]

Éric Araujo added the comment:

Nick being the current shepherd for packaging discussions and the instigator of 
the new version-independent documentation, I’d like to let him take a decision 
on this.

--
assignee: eric.araujo -> ncoghlan
nosy: +ncoghlan
versions: +Python 3.5 -Python 3.2, Python 3.3

___
Python tracker 

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

[issue22915] sax.parser cannot get xml data from a subprocess pipe

[Jocelyn]

New submission from Jocelyn:

With the attached code, and an xml file, I got the following error with python 
3.4.2:

$ cat toto.xml




$ python3.4 toto.py 
Traceback (most recent call last):
  File "toto.py", line 10, in 
parse(proc.stdout, ContentHandler())
  File "/usr/lib/python3.4/xml/sax/__init__.py", line 33, in parse
parser.parse(source)
  File "/usr/lib/python3.4/xml/sax/expatreader.py", line 107, in parse
xmlreader.IncrementalParser.parse(self, source)
  File "/usr/lib/python3.4/xml/sax/xmlreader.py", line 119, in parse
self.prepareParser(source)
  File "/usr/lib/python3.4/xml/sax/expatreader.py", line 111, in prepareParser
self._parser.SetBase(source.getSystemId())
TypeError: must be str, not int


The same test works with python2, and I would expect the code to work with 
python 3 too.


Thanks,
Jocelyn

--
components: XML
messages: 231504
nosy: JocelynJ
priority: normal
severity: normal
status: open
title: sax.parser cannot get xml data from a subprocess pipe
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue22915] sax.parser cannot get xml data from a subprocess pipe

[R. David Murray]

R. David Murray added the comment:

My guess is that this is similar to issue 21044.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue22915] sax.parser cannot get xml data from a subprocess pipe

[R. David Murray]

Changes by R. David Murray :


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

[issue19980] Improve help('non-topic') response

[Mark Lawrence]

Mark Lawrence added the comment:

Anybody?

--

___
Python tracker 

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

[issue19980] Improve help('non-topic') response

[Zachary Ware]

Zachary Ware added the comment:

Mark, did you test your latest patch?

--

___
Python tracker 

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

[issue22915] sax.parser cannot get xml data from a subprocess pipe

[R. David Murray]

R. David Murray added the comment:

I've looked at the sax code, and this does indeed have the same root cause: in 
python2 a dummy string was used for the 'name' attribute of io objects that are 
based on file descriptors, whereas in python3 the name is the integer value of 
the file descriptor.  In test_sax we can see getSystemId being tested that it 
returns a filename (see test_expat_locator_withinfo).

The fix should be analogous to the issue 21044 fix: check that 'name' is a 
string and if not don't use it.  I'm marking this as easy; hopefully someone 
will want to tackle figuring out exactly where in the code it needs to be fixed 
and adding tests for it.

--
keywords: +easy

___
Python tracker 

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

[issue22869] Split pylifecycle.c out from pythonrun.c

[Steve Dower]

Steve Dower added the comment:

That should be the last fix for Windows - a bit of code that was copied into 
the new file but not removed from the old one.

--

___
Python tracker 

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

[issue22869] Split pylifecycle.c out from pythonrun.c

[Roundup Robot]

Roundup Robot added the comment:

New changeset e7df0a47af16 by Steve Dower in branch 'default':
Issue #22869: Remove duplicate stack check from pythonrun.c
https://hg.python.org/cpython/rev/e7df0a47af16

--

___
Python tracker 

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

[issue22869] Split pylifecycle.c out from pythonrun.c

[Zachary Ware]

Zachary Ware added the comment:

Steve, I was actually just minutes away from committing the same fix in the 
opposite direction when I got the notification of your commit.  Nick will 
correct me if I'm wrong but I think PyOS_CheckStack was supposed to stay in 
pythonrun.c, especially since it's still declared in pythonrun.h.

--

___
Python tracker 

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

[issue22869] Split pylifecycle.c out from pythonrun.c

[Steve Dower]

Steve Dower added the comment:

You may be right, I didn't think of looking in the include files. I assumed 
that it was copied without being removed, rather than the copy itself being 
accidental. Feel free to move it back.

--

___
Python tracker 

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

[issue22869] Split pylifecycle.c out from pythonrun.c

[Roundup Robot]

Roundup Robot added the comment:

New changeset 406965684327 by Zachary Ware in branch 'default':
Closes #22869: Move PyOS_CheckStack back to pythonrun.c
https://hg.python.org/cpython/rev/406965684327

--
status: open -> closed

___
Python tracker 

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