[issue24925] Allow doctest to find line number of __test__ strings if formatted as a triple quoted string.

[Nasir Hussain]

Nasir Hussain  added the comment:

Hi, Should I convert patch into PR?
Thanks

--
nosy: +nasirhjafri

___
Python tracker 

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

[issue35804] v3.6.8 _ctypes win32 compiled with pgo crash

[Anselm Kruis]

Change by Anselm Kruis :


Added file: https://bugs.python.org/file48072/test_ctypes.log

___
Python tracker 

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

[issue35804] v3.6.8 _ctypes win32 compiled with pgo crash

[Anselm Kruis]

Change by Anselm Kruis :


--
nosy: +steve.dower

___
Python tracker 

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

[issue32146] multiprocessing freeze_support needed outside win32

[Antoine Pitrou]

Antoine Pitrou  added the comment:

@bbayles Hopefully a Windows user could test if you give a step-by-step guide 
of what to check for.

--
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue35627] multiprocessing.queue in 3.7.2 doesn't behave as it was in 3.7.1

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Hi there. I get this behavior as well, although only in a venv.

Ah, thanks for the clarification.  Then it's a duplicate of issue35797.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> concurrent.futures.ProcessPoolExecutor does not work in venv on 
Windows

___
Python tracker 

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

[issue35804] v3.6.8 _ctypes win32 compiled with pgo crash

[Anselm Kruis]

New submission from Anselm Kruis :

During the QA for Stackless 3.6.8 I observed a crash in _ctypes compiled for 
win32 with PGO, that also exists with plain C-Python v3.6.8. I didn't check 
other versions yet.

OS: Win7 (64bit)
Compiler: Visual Studio 2017 professional 15.9.5

How to reproduce

1. Checkout v3.6.8

I'm using the git-bash
$ git status
HEAD detached at v3.6.8
nothing to commit, working tree clean

2. Clean the sandbox and compile. It is sufficient to use a short pgo-job, but 
the default pgo-job works a well (but takes much more time).

$ cd PCbuild/
$ rm -rf obj win32 amd64
$ PYTHON=/e/Pythons/3.6.4-64/python.exe cmd //c build.bat --pgo-job "-m test 
--pgo test_ctypes" 2>&1 | tee build.log

The file "build.log" is attached. Nothing conspicuous in it.

3. Run the test case ctypes.test.test_win32.WindowsTestCase.test_callconv_1
Sometimes the test passes, sometimes it fails with a Segmentation Fault.

$ win32/python.exe -X faulthandler -m ctypes.test.test_win32 
WindowsTestCase.test_callconv_1
.
--
Ran 1 test in 0.000s

OK

$ win32/python.exe -X faulthandler -m ctypes.test.test_win32 
WindowsTestCase.test_callconv_1
Windows fatal exception: access violation

Current thread 0x1574 (most recent call first):
  File "C:\build\python36\lib\unittest\case.py", line 178 in handle
  File "C:\build\python36\lib\unittest\case.py", line 733 in assertRaises
  File "C:\build\python36\lib\ctypes\test\test_win32.py", line 20 in 
test_callconv_1
  File "C:\build\python36\lib\unittest\case.py", line 605 in run
  File "C:\build\python36\lib\unittest\case.py", line 653 in __call__
  File "C:\build\python36\lib\unittest\suite.py", line 122 in run
  File "C:\build\python36\lib\unittest\suite.py", line 84 in __call__
  File "C:\build\python36\lib\unittest\suite.py", line 122 in run
  File "C:\build\python36\lib\unittest\suite.py", line 84 in __call__
  File "C:\build\python36\lib\unittest\runner.py", line 176 in run
  File "C:\build\python36\lib\unittest\main.py", line 256 in runTests
  File "C:\build\python36\lib\unittest\main.py", line 95 in __init__
  File "C:\build\python36\lib\ctypes\test\test_win32.py", line 165 in 
  File "C:\build\python36\lib\runpy.py", line 85 in _run_code
  File "C:\build\python36\lib\runpy.py", line 193 in _run_module_as_main
Segmentation fault


4. I observed another variant of the crash, if I run all tests in test_ctypes

$ cmd //c rt.bat -q -v test_ctypes 2>&1 | tee test_ctypes.log

The file "test_ctypes.log" is attached. Relevant content:
test_callconv_1 (ctypes.test.test_win32.WindowsTestCase) ... XXX lineno: 124, 
opcode: 0
ERROR
test_callconv_2 (ctypes.test.test_win32.WindowsTestCase) ... XXX lineno: 124, 
opcode: 0
ERROR
test_variant_bool (ctypes.test.test_wintypes.WinTypesTest) ... test test_ctypes 
failed
ok

==
ERROR: test_callconv_1 (ctypes.test.test_win32.WindowsTestCase)
--
Traceback (most recent call last):
  File "C:\build\python36\lib\ctypes\test\test_win32.py", line 27, in 
test_callconv_1
self.assertRaises(ValueError, IsWindow, 0, 0, 0)
  File "C:\build\python36\lib\unittest\case.py", line 733, in assertRaises
return context.handle('assertRaises', args, kwargs)
  File "C:\build\python36\lib\unittest\case.py", line 157, in handle
if not _is_subtype(self.expected, self._base_type):
  File "C:\build\python36\lib\unittest\case.py", line 124, in _is_subtype
if isinstance(expected, tuple):
SystemError: unknown opcode

==
ERROR: test_callconv_2 (ctypes.test.test_win32.WindowsTestCase)
--
Traceback (most recent call last):
  File "C:\build\python36\lib\ctypes\test\test_win32.py", line 36, in 
test_callconv_2
self.assertRaises(ValueError, IsWindow, None)
  File "C:\build\python36\lib\unittest\case.py", line 733, in assertRaises
return context.handle('assertRaises', args, kwargs)
  File "C:\build\python36\lib\unittest\case.py", line 157, in handle
if not _is_subtype(self.expected, self._base_type):
  File "C:\build\python36\lib\unittest\case.py", line 124, in _is_subtype
if isinstance(expected, tuple):
SystemError: unknown opcode

--


I had a quick look at  _call_function_pointer() in Modules/_ctypes/callproc.c, 
but I didn't see anything obvious. A very speculative first guess is the 
calling convention of ffi_call() or a related function written in (inline) 
assembly.

Work around: compile _ctypes for win32 without PGO.

--
components: ctypes
files: build.log
messages: 334202
nosy: anselm.kruis
priority: normal
severity: normal
status: open
title: v3.6.8 _ctypes win32 compiled with pgo crash
type: crash
versions: Python 3.6
Added 

[issue15045] Make textwrap.dedent() and textwrap.indent() handle whitespace consistently

[Nick Coghlan]

Nick Coghlan  added the comment:

Putting some of my comments here rather than on the PR, as they're design 
questions related to "Is the current behaviour actually wrong?" and "Even if 
the current behaviour is deemed technically incorrect, is it worth the risk of 
changing it after all these years?".

I've also retitled the issue to describe the desired outcome of increased 
consistency between textwrap.dedent() and textwrap.indent(), without expressing 
a preference one way or the other.

1. Correctness & consistency

Quoting the textwrap.py comment about ASCII whitespace that Serhiy mentioned:

```
# Hardcode the recognized whitespace characters to the US-ASCII
# whitespace characters.  The main reason for doing this is that
# some Unicode spaces (like \u00a0) are non-breaking whitespaces.
_whitespace = '\t\n\x0b\x0c\r '
```

It's not clear whether or not non-breaking whitespace should actually be 
counted as an empty line, as it wouldn't be a candidate break point for line 
wrapping if that space appeared between two words (e.g. "first\N{NO-BREAK 
SPACE}second"), even though str.split() would split on it, and str.strip() 
would remove it from the beginning or end of a string (and that discrepancy is 
by design, since it's what "non-breaking" *means*).

So the interesting test cases from that perspective would be strings like:

"""\
4 space indent
\N{NO-BREAK SPACE}   4 spaces, but first is no-break
4 space indent
"""
-> textwrap.dedent() should do nothing

"""\
4 space indent
\N{NO-BREAK SPACE}
Previous line is just a single no-break space
"""
-> textwrap.dedent() should do nothing

"""\
4 space indent
\N{NO-BREAK SPACE}5 spaces, but last is no-break
4 space indent
"""
-> textwrap.dedent() should strip the common 4-space prefix

"""\
4 space indent
\N{NO-BREAK SPACE}
Previous line is indented with 4 spaces
"""
-> textwrap.dedent() should strip the common 4-space prefix

The potential inconsistency I cite above is with the then-new textwrap.indent() 
which *does* consider all lines consisting solely of whitespace (whether 
non-breaking or not) to be blank lines, and hence doesn't indent them. This 
means that the following test string wouldn't round trip correctly through a 
textwrap.indent/textwrap.dedent pair:

"""\
4 space indent
\N{NO-BREAK SPACE}
Previous line is indented as usual
"""

indent() would skip adding leading whitespace to the second line, which means 
dedent() would subsequently fail to detect a common leading prefix to be 
stripped.

However, that can easily be considered a bug in textwrap.indent() - it's the 
newer function, so it was a design error to make it inconsistent with the 
textwrap.dedent() precedent.

2. Performance

Since this issue was opened purely on design consistency grounds, it needs to 
offer really compelling benefits if we're going to risk a change that might 
make textwrap.dedent() slower.

I don't think we've reached that bar, as with universal newlines as the default 
text reading behaviour, it's going to be fairly rare for `textwrap.dedent()` to 
be applied to strings containing `\r` or `\r\n`, and if it is, it's a pretty 
straightforward prior normalisation step to convert both of those to `\n` via 
`text.sub('\r\n', '\n').sub('\r', '\n')` (or a comparable regex based on 
https://stackoverflow.com/questions/1331815/regular-expression-to-match-cross-platform-newline-characters)

So I think the most that can be argued for when it comes to the newline 
handling in dedent() is a *documentation* change that notes that 
textwrap.dedent() splits lines strictly on `\n`, and other line endings need to 
be normalized to `\n` before it will work correctly.

That leaves indent(), and I think the case can plausible be made there that it 
should be using _whitespace_only_re for its empty line detection  (the same as 
dedent(), instead of using str.strip().

--
title: Make textwrap.dedent() consistent with str.splitlines(True) and 
str.strip() -> Make textwrap.dedent() and textwrap.indent() handle whitespace 
consistently

___
Python tracker 

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

[issue35791] Unexpected exception with importlib

[Nick Coghlan]

Nick Coghlan  added the comment:

Yep, that's a bug in `py`'s module interface emulation - see the last paragraph 
in https://docs.python.org/3/reference/import.html#module-spec

--
resolution:  -> not a bug
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

[issue35486] subprocess module import hooks breaks back compatibility

[Nick Coghlan]

Nick Coghlan  added the comment:

Aye, we can :)

--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python
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

[issue33416] Add endline and endcolumn to every AST node

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset 9932a22897ef9905161dac7476e6976370e13515 by Ivan Levkivskyi in 
branch 'master':
bpo-33416: Add end positions to Python AST (GH-11605)
https://github.com/python/cpython/commit/9932a22897ef9905161dac7476e6976370e13515


--

___
Python tracker 

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

[issue24925] Allow doctest to find line number of __test__ strings if formatted as a triple quoted string.

[Jurjen N.E. Bos]

Jurjen N.E. Bos  added the comment:

Yes. That would make me happy. In the meantime I learned how to use git, so 
maybe I'll do the pull request myself next time. Thanks for the work.

--

___
Python tracker 

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

[issue34656] [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393

[STINNER Victor]

STINNER Victor  added the comment:

New changeset a4ae828ee416a66d8c7bf5ee71d653c2cc6a26dd by Benjamin Peterson in 
branch 'master':
closes bpo-34656: Avoid relying on signed overflow in _pickle memos. (GH-9261)
https://github.com/python/cpython/commit/a4ae828ee416a66d8c7bf5ee71d653c2cc6a26dd

It seems like this patch changes the implementation of the internal "memo" 
object which is a custom C type in Python 3.

In Python 2 cPickle, the memo is a regular dictionary and so I'm not sure that 
Python 2 is affected by this vulnerability.

Can someone please confirm?

--

___
Python tracker 

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

[issue34656] [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393

[STINNER Victor]

STINNER Victor  added the comment:

> And Modules/cPickle.c is that drastically different?

Stupid me. I was surprised that Python 2.7 had no C accelerator. I was looking 
for Modules/*pickle*.c on my case sensitive Linux filesystem...

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

[issue35805] email package folds msg-id identifiers using RFC2047 encoded words where it must not

[Martijn Pieters]

New submission from Martijn Pieters :

When encountering identifier headers such as Message-ID containing a msg-id 
token longer than 77 characters (including the <...> angle brackets), the email 
package folds that header using RFC 2047 encoded words, e.g.

Message-ID: 
<154810422972.4.16142961424846318...@aaf39fce-569e-473a-9453-6862595bd8da.prvt.dyno.rt.heroku.com>

becomes

Message-ID: =?utf-8?q?=3C154810422972=2E4=2E16142961424846318784=40aaf39fce-?=
 =?utf-8?q?569e-473a-9453-6862595bd8da=2Eprvt=2Edyno=2Ert=2Eheroku=2Ecom=3E?=

The msg-id token here is this long because Heroku Dyno machines use a UUID in 
the FQDN, but Heroku is hardly the only source of such long msg-id tokens. 
Microsoft's Outlook.com / Office365 email servers balk at the RFC2047 encoded 
word use here and attempt to wrap the email in a TNEF winmail.dat attachment, 
then may fail at this under some conditions that I haven't quite worked out yet 
and deliver an error message to the recipient with the helpful message "554 
5.6.0 Corrupt message content", or just deliver the ever unhelpful winmail.dat 
attachment to the unsuspecting recipient (I'm only noting these symptom here 
for future searches).

I encountered this issue with long Message-ID values generated by 
email.util.make_msgid(), but this applies to all RFC 5322 section 3.6.4 
Identification Fields headers, as well as the corresponding headers from RFC 
822 section 4.6 (covered by section 4.5.4 in 5322).

What is happening here is that the email._header_value_parser module has no 
handling for the msg-id tokens *at all*, and email.headerregistry has no 
dedicated header class for identifier headers. So these headers are parsed as 
unstructured, and folded at will.

RFC2047 section 5 on the other hand states that the msg-id token is strictly 
off-limits, and no RFC2047 encoding should be used to encode such elements. 
Because headers *can* exceed 78 characters (RFC 5322 section 2.1.1 states that 
"Each line of characters MUST be no more than 998 characters, and SHOULD be no 
more than 78 characters[.]") I think that RFC5322 msg-id tokens should simply 
not be folded, at all. The obsoleted RFC822 syntax for msg-id makes them equal 
to the addr-spec token, where the local-part (before the @) contains word 
tokens; those would be fair game but then at least apply the RFC2047 encoded 
word replacement only to those word tokens.

For now, I worked around the issue by using a custom policy that uses 998 as 
the maximum line length for identifier headers:

from email.policy import EmailPolicy

# Headers that contain msg-id values, RFC5322
MSG_ID_HEADERS = {'message-id', 'in-reply-to', 'references', 'resent-msg-id'}

class MsgIdExcemptPolicy(EmailPolicy):
def _fold(self, name, value, *args, **kwargs):
if name.lower() in MSG_ID_HEADERS and self.max_line_length - len(name) 
- 2 < len(value):
# RFC 5322, section 2.1.1: "Each line of characters MUST be no
# more than 998 characters, and SHOULD be no more than 78
# characters, excluding the CRLF.". To avoid msg-id tokens from 
being folded
# by means of RFC2047, fold identifier lines to the max length 
instead.
return self.clone(max_line_length=998)._fold(name, value, *args, 
**kwargs)
return super()._fold(name, value, *args, **kwargs)

This ignores the fact that In-Reply-To and References contain foldable 
whitespace in between each msg-id, but it at least let us send email through 
smtp.office365.com again without confusing recipients.

--
components: email
messages: 334210
nosy: barry, mjpieters, r.david.murray
priority: normal
severity: normal
status: open
title: email package folds msg-id identifiers using RFC2047 encoded words where 
it must not
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue35683] Enable manylinux1 builds on Pipelines for CI testing

[Steve Dower]

Steve Dower  added the comment:

As mentioned above, those changes are other improvements that were worth 
taking, and about half of the required manylinux1 changes. But we probably need 
to maintain our own manylinux image for building/running CPython tests, if we 
want to do it. The existing images are all designed for having CPython already 
present to build a range of binaries, which is not at all our use case.

--
stage: patch review -> needs patch

___
Python tracker 

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

[issue35800] remove smtpd.MailmanProxy

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Jan 22, 2019, at 07:16, Samuel Colvin  wrote:
> 
> Ok, if I create a PR, should it just remove MailmanProxy completely or mark 
> it as deprecated in the docs to be removed in 3.9?
> 
> Personally, I think it should be ok to remove it completely since it hasn't 
> been working at all for the last 4 minor versions.

True, but I think we should stick to the normal deprecation process, just to be 
safe.

--

___
Python tracker 

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

[issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl when using the CLI flag

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Lucas Cimon!

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

[issue35713] Fatal Python error: _PySys_BeginInit: can't initialize sys module

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +11435

___
Python tracker 

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

[issue27035] Cannot set exit code in atexit callback

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

@ Kumar Do you want to make a PR fixing the docs?

--

___
Python tracker 

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

[issue27035] Cannot set exit code in atexit callback

[Kumar Akshay]

Kumar Akshay  added the comment:

Can I work on this?
I noticed the same behaviour as python3.7 in python3.8 from master branch.

--
nosy: +kakshay

___
Python tracker 

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

[issue35806] typing module adds objects to sys.modules that don't look like modules

[Guido van Rossum]

Guido van Rossum  added the comment:

OK, I don't see a bug here. The docs for sys.modules are pretty vague -- I 
don't believe they imply that all values in sys.modules must have every 
attribute of a Module object.

--
resolution:  -> wont fix
stage: test needed -> 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

[issue35806] typing module adds objects to sys.modules that don't look like modules

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The reason I filed #35791 is that I'm rewriting modulegraph[1] using importlib 
and run into some problems due to importlib.util.find_spec() failing for names 
that are already imported. 

Working around that in general probably will require reimplementing bits of 
importlib in my own code and that's something I'd prefer to avoid. The 
alternative appears to be messing with sys.modules when I run into this 
problem, which might cause other problem.

BTW. The lack of __spec__ on typing.io and typing.re is not a problem for me, I 
can use the machinery I already have to insert edges for C extensions to do the 
right thing for these modules as well. 

[1] https://modulegraph.readthedocs.io/en/latest/

--

___
Python tracker 

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

[issue35779] Print friendly version message in REPL

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> We only print simplified message in official binary release, any 
> Linux/private builds still using the current message. We know enough 
> information about official binary release.

Who is "we" in this sentence?

Are you saying that the Python.org binary releases here:

https://www.python.org/downloads/release/python-372/

for example don't print the same information as source releases? I 
don't have either Windows or Mac and so cannot test it for myself.

> Junior users are people such as students learning programming in 
> middle school, I think git information will confuse them, maybe many 
> of them will never know git knowledges.

Why is this important? Surely they won't be tested on their 
understanding of the git tag information printed at startup. They can 
just ignore the information.

If you are really going to push this idea that the information currently 
printed at startup is confusing to beginners, then we can ask educators 
like Raymond Hettinger and others who have been teaching Python for many 
years and see what their experience has been.

But for what it is worth, in 15+ years of asking questions from 
beginners on various mailing lists, I don't believe I have ever seen 
anyone ask about that information. If it happens, it happens rarely.

> Another problem is indicating 32bit or 64bit build, IMHO this is an 
> useful information.

And that information is currently printed at startup.

--

___
Python tracker 

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

[issue27035] Cannot set exit code in atexit callback

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

The behaviour regarding printing SytemExit was changed by Serhiy in 
3fd54d4a7e604067e2bc0f8cfd58bdbdc09fa7f4 and in bpo-28994.

--

___
Python tracker 

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

[issue35713] Fatal Python error: _PySys_BeginInit: can't initialize sys module

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 6d43f6f081023b680d9db4542d19b9e382149f0a by Victor Stinner in 
branch 'master':
bpo-35713: Split _Py_InitializeCore into subfunctions (GH-11650)
https://github.com/python/cpython/commit/6d43f6f081023b680d9db4542d19b9e382149f0a


--

___
Python tracker 

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

[issue35795] test_pkgutil test_zipapp fail in AMD64 Windows7 SP1 3.x and AMD64 Windows7 SP1 3.7 buildbots

[Steve Dower]

Steve Dower  added the comment:

I recently added (and even more recently fixed) the "--tempdir" option for 
libregrtest, so that can be used to specify a temporary location for *most* 
tests. Some still ignore that setting (notably distutils), but it's a starting 
point.

I agree that tests need to be cleaning up completely after themselves, but when 
they fail it's often better to leave the files behind for investigation. Having 
buildbots clean up completely seems fine to me.

--
nosy: +steve.dower

___
Python tracker 

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

[issue35806] typing module adds objects to sys.modules that don't look like modules

[Ronald Oussoren]

Ronald Oussoren  added the comment:

In response to my previous message: "Messing" with sys.modules appears to be 
good enough work around for me, at least in the limited testing I've done so 
far. The new version of modulegraph hasn't seen any testing beyond a largish 
set of unit tests though.

--

___
Python tracker 

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

[issue35683] Enable manylinux1 builds on Pipelines for CI testing

[Steve Dower]

Steve Dower  added the comment:


New changeset 128efcade63480b5860a6d045a41ba4abf5eea2f by Steve Dower in branch 
'3.7':
bpo-35683: Improve Azure Pipelines steps (GH-11493)
https://github.com/python/cpython/commit/128efcade63480b5860a6d045a41ba4abf5eea2f


--

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[Eryk Sun]

Eryk Sun  added the comment:

> The current solution is the simplest one that ensures the most 
> compatibility for the least amount of risk, even though that 
> was not zero risk, as we've seen. 

How about making the py[w].exe launcher unset __PYVENV_LAUNCHER__ whenever it 
runs a registered version explicitly?

We could also modify the embedded-script (entry-point) launchers, which would 
be simpler if we had them in core instead of distlib. They could be updated to 
look for pyvenv.cfg. If found, it would override the shebang and set the 
__PYVENV_LAUNCHER__ environment variable. This would eliminate the interjected 
process in a 3.7.2 virtual environment, e.g. pip.exe -> python.exe (venv 
launcher) -> python.exe (installed) would become pip.exe -> python.exe 
(installed). More importantly, it would unset __PYVENV_LAUNCHER__ in case it's 
not a virtual environment script. 

This way running pip.exe for an installed Python won't end up installing into a 
virtual environment, as can happen now in 3.7.2. For example:

>>> print(os.environ['__PYVENV_LAUNCHER__'])
C:\Temp\env37\Scripts\python.exe

>>> import requests
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'requests'

>>> pip = 'Scripts\\pip.exe'
>>> out = subprocess.check_output('{} install requests'.format(pip))

>>> import requests
>>> requests.__version__
'2.21.0'

Note that "Scripts\\pip.exe" in a CreateProcess command line gets resolved 
first relative to the application directory, before trying the current 
directory, system directories, and PATH directories.

--

___
Python tracker 

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

[issue33416] Add endline and endcolumn to every AST node

[Emily Morehouse]

Change by Emily Morehouse :


--
pull_requests: +11441

___
Python tracker 

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

[issue27035] Cannot set exit code in atexit callback

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I think this is a documentation issue today. The docs say:

>If an exception is raised during execution of the exit handlers, a traceback
>is printed (unless SystemExit is raised) and the exception 
>information is saved. After all exit handlers have had a chance to run the
>last exception to be raised is re-raised.

Which is true except for two things:

- SystemExit is not covered by the paragraph (it just says that SystemExit will 
not print a traceback but what actually happens is that is ignored).
- The last exception is not re-raised (as it was on Python2.7).

I think we should update the docs to reflect that SystemExit is ignored and to 
remove that the last exception is re-raised.

--
nosy: +pablogsal

___
Python tracker 

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

[issue5038] urrlib2/httplib doesn't reset file position between requests

[David Heiberg]

Change by David Heiberg :


--
nosy: +dheiberg

___
Python tracker 

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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[Yuuji KAWAMATSU]

Change by Yuuji KAWAMATSU :


--
keywords: +patch
pull_requests: +11442
stage:  -> patch review

___
Python tracker 

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

[issue20911] urllib 'headers' is not a well defined data type

[Demian Brecht]

Demian Brecht  added the comment:

@R. David Murray

Is this issue still valid? Running 3.6 it seems that http and ftp are 
consistent at any rate (http returns http.client.HTTPMessage and ftp returns 
email.message.Message). If it's still an issue, could you please elaborate?

--

___
Python tracker 

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

[issue35779] Print friendly version message in REPL

[Ma Lin]

Ma Lin  added the comment:

Hi, thanks for your replies.

To be honest, the reason is I fell it's a bit ugly, this line is very long at 
REPL startup. And the information is not very clear [1].

I'm not strongly pushing this idea, just raise my feeling, keep it easy. :)

Yes, after this discussion, I suppose simplified message only printed in 
Windows/Mac official binary releases. Just print at REPL startup, don't change 
sys.version.

Python 3.7.2 (64 bit, Dec 23 2018) on Windows
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.version
'3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit 
(AMD64)]'


[1] How do I determine if my python shell is executing in 32bit or 64bit mode 
on OS X?
[1] 
https://stackoverflow.com/questions/1405913/how-do-i-determine-if-my-python-shell-is-executing-in-32bit-or-64bit-mode-on-os

--

___
Python tracker 

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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[Yuuji KAWAMATSU]

Change by Yuuji KAWAMATSU :


--
keywords: +patch, patch
pull_requests: +11442, 11443
stage:  -> patch review

___
Python tracker 

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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[Yuuji KAWAMATSU]

Change by Yuuji KAWAMATSU :


--
keywords: +patch, patch, patch
pull_requests: +11442, 11443, 11444
stage:  -> patch review

___
Python tracker 

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

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

[Steve Dower]

Steve Dower  added the comment:

> How about making the py[w].exe launcher unset __PYVENV_LAUNCHER__ whenever it 
> runs a registered version explicitly?

I think this is a good idea, though it can be unset unconditionally. If we're 
in a virtual environment, then it will run the intermediate process which will 
set the variable again (this is unavoidable unless we include specialized 
knowledge in the launcher to find the base python.exe from the pyvenv.cfg, 
which I'd rather not duplicate in so many places, when you consider that the 
script launcher will need it too).

As for updating the script launchers, on one hand I'd love to have them, but on 
the other it's more for us to maintain and there's definitely been benefit from 
it being backported for us. As long as they run the correct python.exe, I think 
it's fine.

I think that CreateProcess oddity where it searches the current process's 
directory first is going to catch people out regardless (I'm surprised it 
hasn't come up before), but I guess most people play it safe and use full paths.

--

___
Python tracker 

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

[issue35791] Unexpected exception with importlib

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I expected as much. 

I've filed an issue with apipkg for this: 
https://github.com/pytest-dev/apipkg/issues/13. 

My next challenge is to find a way to work around this issue in my code.

BTW. Typing.io is a namespace added to sys.modules by the typing module that 
also does not have __spec__, and causes similar problems. I have an simple 
workaround for that on my side.

--

___
Python tracker 

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

[issue35804] v3.6.8 _ctypes win32 compiled with pgo crash

[Steve Dower]

Steve Dower  added the comment:

We already compile 32-bit CPython without PGO on Windows, so I don't think 
there's anything to do here apart from record the issue.

It's very likely that 3.8 will finally get an updated libffi, which should deal 
with this completely (or force us to take another look). 3.6 is not getting 
more binary releases though, and 3.7 would need a targeted fix if it repros 
there, so all we can really do is close this issue, unless you have additional 
info on its impact?

--

___
Python tracker 

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

[issue35800] remove smtpd.MailmanProxy

[Samuel Colvin]

Samuel Colvin  added the comment:

Ok, if I create a PR, should it just remove MailmanProxy completely or mark it 
as deprecated in the docs to be removed in 3.9?

Personally, I think it should be ok to remove it completely since it hasn't 
been working at all for the last 4 minor versions.

--

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[Vinay Sajip]

Change by Vinay Sajip :


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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset cda73a5af2ff064ca82140342b3158851d43868f by Vinay Sajip 
(yuji38kwmt) in branch 'master':
bpo-35781: Changed references to deprecated 'warn' method in logging 
documentation in favour of 'warning' (GH-11654)
https://github.com/python/cpython/commit/cda73a5af2ff064ca82140342b3158851d43868f


--

___
Python tracker 

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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[Vinay Sajip]

Change by Vinay Sajip :


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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset 3be19c082b7f0ba3cf6c28922d3577126871788e by Vinay Sajip (Miss 
Islington (bot)) in branch '3.7':
bpo-35781: Changed references to deprecated 'warn' method in logging 
documentation in favour of 'warning' (GH-11654) (GH-11657)
https://github.com/python/cpython/commit/3be19c082b7f0ba3cf6c28922d3577126871788e


--

___
Python tracker 

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

[issue35808] Let's retire pgen

[Guido van Rossum]

New submission from Guido van Rossum :

Pgen is literally the oldest piece of technology in the CPython repo -- it was 
the first thing I wrote for Python over 29 years ago. It's not aged well, and 
building it requires various #if[n]def PGEN hacks in other parts of the code; 
it also depends more and more on CPython internals. There already is a 
replacement written in pure Python (Lib/lib2to3/pgen/), it just needs some glue 
to actually generate the graminit.[ch] files. Note that several other essential 
generation steps (everything listed for regen-all except regen-importlib and 
clinic) already depend on having a working Python interpreter around, so let's 
not worry about the bootstrapping process.

--
components: Build
messages: 334247
nosy: gvanrossum
priority: low
severity: normal
stage: needs patch
status: open
title: Let's retire pgen
versions: Python 3.8

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[miss-islington]

Change by miss-islington :


--
keywords: +patch
pull_requests: +11445

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset f0c743604fc841d35a48822b936ef2e5919e43c1 by Vinay Sajip (Géry 
Ogam) in branch 'master':
bpo-35722: Updated the documentation for the 'disable_existing_loggers' 
parameter (GH-11525)
https://github.com/python/cpython/commit/f0c743604fc841d35a48822b936ef2e5919e43c1


--

___
Python tracker 

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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests:  -11444

___
Python tracker 

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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests:  -11443

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset 552478bb1086ef371e4f1da0b430b90eba4785d5 by Vinay Sajip (Miss 
Islington (bot)) in branch '3.7':
bpo-35722: Updated the documentation for the 'disable_existing_loggers' 
parameter (GH-11525) (GH-11655)
https://github.com/python/cpython/commit/552478bb1086ef371e4f1da0b430b90eba4785d5


--

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests:  -11447

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests:  -11446

___
Python tracker 

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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests:  -11452

___
Python tracker 

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

[issue35808] Let's retire pgen

[Ethan Smith]

Change by Ethan Smith :


--
nosy: +Ethan Smith

___
Python tracker 

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

[issue35766] Merge typed_ast back into CPython

[Ethan Smith]

Change by Ethan Smith :


--
nosy: +Ethan Smith

___
Python tracker 

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

[issue35726] QueueHandler formating affects other handlers

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset da6424e96ada72c15c91bddb0a411acf7119e10a by Vinay Sajip 
(Manjusaka) in branch 'master':
bpo-35726: Prevented QueueHandler formatting from affecting other handlers 
(GH-11537)
https://github.com/python/cpython/commit/da6424e96ada72c15c91bddb0a411acf7119e10a


--

___
Python tracker 

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

[issue35726] QueueHandler formatting affects other handlers

[Vinay Sajip]

Vinay Sajip  added the comment:

Merged for 3.8, will add backport labels to PR in due course.

--
title: QueueHandler formating affects other handlers -> QueueHandler formatting 
affects other handlers

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[miss-islington]

Change by miss-islington :


--
keywords: 
pull_requests: +11446, 11447, 11449, 11450

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[miss-islington]

Change by miss-islington :


--
keywords: +patch, patch, patch, patch, patch
pull_requests: +11445, 11446, 11447, 11448, 11449, 11450

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[miss-islington]

Change by miss-islington :


--
keywords: +patch, patch
pull_requests: +11445, 11446

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[miss-islington]

Change by miss-islington :


--
keywords: +patch, patch, patch, patch
pull_requests: +11445, 11446, 11447, 11449

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[miss-islington]

Change by miss-islington :


--
keywords: +patch, patch, patch
pull_requests: +11445, 11446, 11447

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests:  -11450

___
Python tracker 

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

[issue35722] disable_existing_loggers does not apply to the root logger

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests:  -11449

___
Python tracker 

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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[miss-islington]

Change by miss-islington :


--
pull_requests: +11451, 11453

___
Python tracker 

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

[issue35781] `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests:  -11453

___
Python tracker 

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

[issue35713] Fatal Python error: _PySys_BeginInit: can't initialize sys module

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +11435, 11436, 11437

___
Python tracker 

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

[issue33416] Add endline and endcolumn to every AST node

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Buildbots are green, this can be now closed.

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

[issue35804] v3.6.8 _ctypes win32 compiled with pgo crash

[Anselm Kruis]

Anselm Kruis  added the comment:

Closing the issue is perfectly OK for me. I just want to document the problem, 
because there is no bpo ticket yet and Tools/msi/README.txt does not mention 
any problems with PGO either.

3.7 and master might be affected too, but I didn't observe this issue with 
3.7.2, when I did the QA testing for Stackless 3.7.2 a few days ago.

Otherwise a PGO optimized build seems to work quite well.

--

___
Python tracker 

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

[issue35807] Update bundled pip to 19.0

[Pradyun Gedam]

New submission from Pradyun Gedam :

In line with https://bugs.python.org/issue35277.

Will also update setuptools while I do this. (if no one else gets to it, I'll 
file a PR tomorrow morning)

--
components: Library (Lib)
messages: 334230
nosy: dstufft, ncoghlan, paul.moore, pradyunsg
priority: normal
severity: normal
status: open
title: Update bundled pip to 19.0

___
Python tracker 

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

[issue35713] Fatal Python error: _PySys_BeginInit: can't initialize sys module

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +11430, 11431

___
Python tracker 

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

[issue35713] Fatal Python error: _PySys_BeginInit: can't initialize sys module

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +11430, 11431, 11432

___
Python tracker 

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

[issue35713] Fatal Python error: _PySys_BeginInit: can't initialize sys module

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +11430

___
Python tracker 

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

[issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl when using the CLI flag

[miss-islington]

miss-islington  added the comment:


New changeset f71e7433ebccb2e3a2665b93bb84de38f9c581c8 by Miss Islington (bot) 
in branch '3.7':
bpo-35720: Fixing a memory leak in pymain_parse_cmdline_impl() (GH-11528)
https://github.com/python/cpython/commit/f71e7433ebccb2e3a2665b93bb84de38f9c581c8


--
nosy: +miss-islington

___
Python tracker 

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

[issue35802] os.stat / os.lstat always present, but code checks hastattr(os, 'stat') / hasattr(os, 'lstat')

[Gregory P. Smith]

Gregory P. Smith  added the comment:

I suspect these conditionals are very old and came from times when we supported 
some platforms that did not have these APIs.

Are they present on all CPython supported platforms today?

Windows is probably the only one left to verify.

BSD/Linux/Un*xes and modern macOS are POSIX.

macOS <= 9 (classic) has long since died.

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

[issue35683] Enable manylinux1 builds on Pipelines for CI testing

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +11438, 11439, 11440

___
Python tracker 

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

[issue35804] v3.6.8 _ctypes win32 compiled with pgo crash

[Steve Dower]

Change by Steve Dower :


--
resolution:  -> out of date
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

[issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl when using the CLI flag

[miss-islington]

Change by miss-islington :


--
pull_requests: +11433

___
Python tracker 

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

[issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl when using the CLI flag

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 35ca1820e19f81f69073f294503cdcd708fe490f by Victor Stinner (Lucas 
Cimon) in branch 'master':
bpo-35720: Fixing a memory leak in pymain_parse_cmdline_impl() (GH-11528)
https://github.com/python/cpython/commit/35ca1820e19f81f69073f294503cdcd708fe490f


--

___
Python tracker 

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

[issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl when using the CLI flag

[miss-islington]

Change by miss-islington :


--
pull_requests: +11433, 11434

___
Python tracker 

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

[issue35713] Fatal Python error: _PySys_BeginInit: can't initialize sys module

[STINNER Victor]

STINNER Victor  added the comment:


New changeset bf4ac2d2fd520c61306b2676db488adab9b5d8c5 by Victor Stinner in 
branch 'master':
bpo-35713: Rework Python initialization (GH-11647)
https://github.com/python/cpython/commit/bf4ac2d2fd520c61306b2676db488adab9b5d8c5


--

___
Python tracker 

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

[issue35805] email package folds msg-id identifiers using RFC2047 encoded words where it must not

[R. David Murray]

R. David Murray  added the comment:

Yes, the correct solution would be to write an actual parser for headers 
containing message ids.  All the pieces needed to do this already exist in 
_header_value_parser, it "just" needs a function that glues them together in 
the right order, and then apply that new top-level parser to the appropriate 
headers via headerregistry.

See also issue 34881.

--
stage:  -> needs patch

___
Python tracker 

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

[issue35802] os.stat / os.lstat always present, but code checks hastattr(os, 'stat') / hasattr(os, 'lstat')

[Anthony Sottile]

Anthony Sottile  added the comment:

yep! did my due diligence there, you can check my work on 
https://github.com/python/cpython/pull/11643

all platforms have these functions since `posixmodule.c` is always compiled and 
the functions in question are not guarded by preprocessor directives in any way

--

___
Python tracker 

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

[issue35713] Fatal Python error: _PySys_BeginInit: can't initialize sys module

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +11435, 11436

___
Python tracker 

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

[issue35683] Enable manylinux1 builds on Pipelines for CI testing

[Steve Dower]

Steve Dower  added the comment:


New changeset 28f6cb34f602b9796987904a607dceaf2e4a9e78 by Steve Dower in branch 
'master':
bpo-35683: Improve Azure Pipelines steps (GH-11493)
https://github.com/python/cpython/commit/28f6cb34f602b9796987904a607dceaf2e4a9e78


--

___
Python tracker 

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

[issue35683] Enable manylinux1 builds on Pipelines for CI testing

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +11438, 11439

___
Python tracker 

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

[issue35683] Enable manylinux1 builds on Pipelines for CI testing

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +11438

___
Python tracker 

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

[issue35779] Print friendly version message in REPL

[Eric Snow]

Eric Snow  added the comment:

Hi Ma Lin!  Thanks for the suggestion.  We appreciate your interest in making 
Python better.

It's unclear from your messages what is motivating your request.  You mentioned 
middle school students, but that didn't sound like your actual motivator.  
Knowing what problems the current message has caused will help us identify the 
appropriate solution (including potentially the one you've suggested).  So 
would you mind clarifying what would be the concrete value of simplifying the 
initial version message printed by the REPL?

As Steven noted, there are several valid reasons to keep the message as-is:

* it's pretty much the same as it's always been (this matters because, for 
better or worse, sometimes people rely on the format)
* the full information can be useful when a user submits a bug report here
* the code that produces that version string is simpler (granted, the 
maintenance burden wouldn't change much)
* any change introduces churn (though this wouldn't cause much, it's still 
something)
* "status quo wins a stalemate" [1]

Also note that the REPL version messages (along with `sys.version`) aren't 
particularly useful for programatically dealing with the Python version.  Here 
are better options for that:

* python3 --version
* sys.version_info

Finally, I'd strongly recommend that you submit a pull request to go along with 
this issue.  If we've done a good job then you should find the experience 
rewarding, even if the PR is rejected.  The change should be fairly small and 
localized to one place in one file.  Don't forget to add yourself to the 
Misc/ACKS file. :)  If you'd like some help then check out the "core 
mentorship" resources. [2]  The mailing list is a great place to start.  We'd 
love to add you to our growing list of contributors.


[1] 
https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html
[2] https://www.python.org/dev/core-mentorship/

--
nosy: +eric.snow

___
Python tracker 

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

[issue35806] typing module adds objects to sys.modules that don't look like modules

[Eric Snow]

New submission from Eric Snow :

tl;dr Should all objects in sys.modules look like module objects?

In #35791 Ronald described a problem with a "module" added to sys.modules that 
does not have all the attributes a module should have.  He also mentioned a 
similar problem with typing.io [1]:

BTW. Typing.io is a namespace added to sys.modules by
the typing module that also does not have __spec__, and
causes similar problems. I have an simple workaround for
that on my side.

I've verified the missing module attributes (using 3.8):

>>> old = sorted(sys.modules)
>>> import typing
>>> new = sorted(sys.modules)
>>> assert sorted(set(old) - set(new)) == []
>>> sorted(set(new) - set(old))
['_collections', '_functools', '_heapq', '_locale',
 '_operator', '_sre', 'collections', 'collections.abc',
 'contextlib', 'copyreg', 'enum', 'functools', 'heapq',
 'itertools', 'keyword', 'operator', 're', 'reprlib',
 'sre_compile', 'sre_constants', 'sre_parse', 'types',
 'typing', 'typing.io', 'typing.re']
>>> [name for name in vars(sys.modules['typing.io']) if 
name.startswith('__')]
['__module__', '__doc__', '__all__', '__dict__', '__weakref__']
>>> [name for name in vars(sys.modules['typing.re']) if 
name.startswith('__')]
['__module__', '__doc__', '__all__', '__dict__', '__weakref__']

Per the language reference [2], modules should have the following attributes:

__name__
__loader__
__package__
__spec__

Modules imported from files also should have __file__ and __cached__.  (For the 
sake of completeness, packages also should have a __path__ attribute.)

As seen above, typing.io and typing.re don't have any of the import-related 
attributes.

So, should those two "modules" have all those attributes added?  I'm in favor 
of saying that every sys.modules entry must have all the appropriate 
import-related attributes (but doesn't have to be an actual module object).  
Otherwise tools (e.g. importlib.reload(), Ronald's) making that (arguably 
valid) assumption break.  The right place for the change in the language 
reference is probably the "module cache" section. [3]  The actual entry for 
sys.modules [4] is probably fine as-is.


[1] https://bugs.python.org/issue35791#msg334212
[2] https://docs.python.org/3/reference/import.html#module-spec
[3] https://docs.python.org/3/reference/import.html#the-module-cache
[4] https://docs.python.org/3/library/sys.html#sys.modules

--
components: Library (Lib)
messages: 334222
nosy: barry, brett.cannon, eric.snow, gvanrossum, ncoghlan, ronaldoussoren
priority: normal
severity: normal
stage: test needed
status: open
title: typing module adds objects to sys.modules that don't look like modules
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue35791] Unexpected exception with importlib

[Eric Snow]

Eric Snow  added the comment:

FYI, I opened #35806 for typing.io.

--

___
Python tracker 

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

[issue35806] typing module adds objects to sys.modules that don't look like modules

[Guido van Rossum]

Guido van Rossum  added the comment:

It's been a somewhat well-known idiom for modules to replace themselves in 
sys.modules with an object that implements some special behaviors (e.g. dynamic 
loading). This "just works" and AFAIK people have been doing this for ages. 
Typically such classes just implement enough machinery so that "import foo; 
print(foo.bar)" works -- everything else (__file__, __doc__ etc.) is optional.

So I think tools should be robust when they inspect sys.modules and not crash 
or whine loudly when they find something that's missing a few advanced 
attributes.

That said, if there's something *useful* we could put in the special attributes 
for e.g. typing.io, I'm not against it. But I don't think this is a bug.

--
priority: normal -> low

___
Python tracker 

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