[issue31113] Stack overflow with large program

Serhiy Storchaka added the comment: I concur with Stefan. Some parts of the compiler are recursive. The crash is expected for enough complex programs, and the size of C stack is platform depended. There are few hard-coded limits (MAXINDENT, CO_MAXBLOCKS) that may prevent the crash by

[issue31108] add __contains__ for list_iterator (and others) for better performance

Terry J. Reedy added the comment: Sorry, I mistakenly assumed, without carefully checking the C code, that the speedup was from checking the underlying collection, without advancing the iterator. I presume that " ++it->it_index;" is the statement to the contrary. I should have either asked

[issue31108] add __contains__ for list_iterator (and others) for better performance

Changes by Terry J. Reedy : -- Removed message: http://bugs.python.org/msg299770 ___ Python tracker ___

[issue31108] add __contains__ for list_iterator (and others) for better performance

Serhiy Storchaka added the comment: Terry, this proposition doesn't change the behavior. It moves the iterator forward during searching. The only effect is inlining __next__ in a loop and getting rid of the overhead of few indirections and calls. --

[issue31113] Stack overflow with large program

Terry J. Reedy added the comment: We know that compile has undocumented size limits of various sorts that are usually more than sufficient for normal human written code but which can be overwhelmed by machine-generated code. We do not regard this as a bug. However, 20 levels of if-nesting

[issue31082] reduce takes iterable, not just sequence

Serhiy Storchaka added the comment: Yes, I think it can. But be aware that "sequence" is used not only in the signature, but in following description. The term "sequence" in the documentation and the docstring looks to me like a synonym of "iterable", not a reference to

[issue31108] add __contains__ for list_iterator (and others) for better performance

Terry J. Reedy added the comment: On my particular Win 10 machine with 3.6, the times are 1.52 and 2.14. But to me, the times are irrelevant. A performance enhancement, by definition, should not change computational results, but this does. If an iterator is a standard iterator, then 'x in

[issue31100] unable to open python on Windows

Changes by Terry J. Reedy : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware title: unable to open python -> unable to open python on Windows ___ Python tracker

[issue31097] itertools.islice not accepting np.int64

Terry J. Reedy added the comment: LB, an exception is a graceful shutdown, not a crash. A crash is a seg fault, core dump, or an OS message 'Your app has stopped unexpectedly'. In #30537, the exception was regarded as expected, not a bug, and changing islice to accept np ints was regarded as

[issue31097] itertools.islice not accepting np.int64

Changes by Terry J. Reedy : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Using PyNumber_AsSsize_t in itertools.islice type: crash -> behavior ___ Python tracker

[issue31082] reduce takes iterable, not just sequence

Terry J. Reedy added the comment: Serhiy, given that the parameters of reduce are currently positional only (by experiment, it has not gotten the C.A. treatment yet), can 'sequence' in the signature in the docstring be changes to 'iterable'? -- nosy: +serhiy.storchaka, terry.reedy

[issue31123] fnmatch does not follow Unix fnmatch functionality

R. David Murray added the comment: Looking at the fnmatch man page, it looks like there are option flags that some shells use that our fnmatch doesn't support. I'm not sure if supporting them is a good idea for us or not, but it is probably worth discussing. I suspect our fnmatch was

[issue31122] SSLContext.wrap_socket() throws OSError with errno == 0

Martin Panter added the comment: It might help if you explained what “atrocities” are happening on your network. Is there a proxy or man-in-the-middle (or the remote peer) that shuts down TCP connections? If so, perhaps this is similar to Issue 10808. From my memory, in that case an OS

[issue29304] dict: simplify lookup functions

Raymond Hettinger added the comment: It would have been nice to have timed this on ARM chips or 32-bit builds. I suspect that the previous code was mainly beneficial in register starved environments when it would have saved some memory accesses whenever there were an immediate first hit on a

[issue31123] fnmatch does not follow Unix fnmatch functionality

Changes by R. David Murray : -- type: behavior -> enhancement versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker

[issue31123] fnmatch does not follow Unix fnmatch functionality

R. David Murray added the comment: I don't believe there is an equivalent unix command. Are you referring to the fnmatch glibc function? Can you demonstrate the differences? I doubt we will change the functionality, but that would be the minimum starting point for a discussion. --

[issue31123] fnmatch does not follow Unix fnmatch functionality

New submission from Varun Agrawal: Currently, the fnmatch module in Python does not operate like the Unix equivalent command. This is especially the case with patterns such as `dir/` which does not match directory path returned by `os` (which would be `dir`) and neither does the pattern match

[issue31115] Py3.6 threading/reference counting issues with `numexpr`

Robert McLeod added the comment: After building with Python3.7 I was able to get a useful error message that `PyMem` functions were being called inside GIL release. I will replace these with C-equivalents and try with Python 3.6. Fatal Python error: Python memory allocator called without

[issue31107] copyreg does not properly mangle __slots__ names

Changes by Shane Harvey : -- pull_requests: +3039 ___ Python tracker ___ ___

[issue31107] copyreg does not properly mangle __slots__ names

Changes by Shane Harvey : -- pull_requests: +3038 ___ Python tracker ___ ___

[issue31119] Signal tripped flags need memory barriers

Nathaniel Smith added the comment: @arigo: Technically we also need that the writes to memory are observed to happen-before the write() call on the wakeup fd, which is not something that Intel is going to make any guarantees about. But *probably* this is also safe because the kernel has to

[issue31119] Signal tripped flags need memory barriers

Armin Rigo added the comment: For reference, no, it can't happen on x86 or x86-64. I've found that this simplified model actually works for reasoning about ordering at the hardware level: think about each core as a cache-less machine that always *reads* from the central RAM, but that has a

[issue31122] SSLContext.wrap_socket() throws OSError with errno == 0

New submission from Nikolaus Rath: With a particularly atrocious network connection, I often get the following exception: File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 503, in connect self._sock = self.ssl_context.wrap_socket(self._sock, server_hostname=server_hostname)

[issue31103] Windows Installer Product Version 3.6.2150.0 Offset By 0.0.150.0

Damon Atkins added the comment: To Summaries A) Name/DisplayName "Python 3.X (64-bit)" or "Python 3.X.Y" (64-bit) "Python 3.X (64-bit)" would match the install directory which is \Python3X (this should be \Python3.X) Display Version should start with 3.X.Y or 3.X.Y. version DWORD in the

[issue31103] Windows Installer Product Version 3.6.2150.0 Offset By 0.0.150.0

Markus Kramer added the comment: Steve, yes: from my point of view, the version in "Programs and Features" should be 3.6.2 or 3.6.2.0 or 3.6.2.150. Eryk, thank you for your explanation - I had a wrong memory about the third field in ProductVersion to be the micro version and learned

[issue31119] Signal tripped flags need memory barriers

Nathaniel Smith added the comment: On further investigation (= a few hours staring at the ceiling last night), it looks like there's another explanation for my particular bug... which is good, because on further investigation (= a few hours squinting at google results) it looks like this

[issue30841] Fix a variable shadowing warning in Python-ast.c

Łukasz Langa added the comment: Thanks! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue30841] Fix a variable shadowing warning in Python-ast.c

Changes by Łukasz Langa : -- pull_requests: +3037 ___ Python tracker ___ ___

[issue30841] Fix a variable shadowing warning in Python-ast.c

Łukasz Langa added the comment: The actual change is just three lines in asdl_c.py. Python-ast.c is generated. -- nosy: +lukasz.langa ___ Python tracker

[issue23702] docs.python.org/3/howto/descriptor.html still refers to "unbound methods"

Raymond Hettinger added the comment: We have a sprint in early September and I'll fix it then. -- ___ Python tracker ___

[issue31113] Stack overflow with large program

Antoine Pitrou added the comment: I'm not an expert in the compiler myself. -- nosy: +benjamin.peterson, brett.cannon, ncoghlan, serhiy.storchaka, yselivanov ___ Python tracker

[issue26618] _overlapped extension module of asyncio uses deprecated WSAStringToAddressA() function

Segev Finer added the comment: It was fixed here: https://github.com/python/cpython/commit/cc16be85c0b7119854c00fb5c666825deef641cf#diff-1308fc2ab05154373172f10e931c78f0L986. So it's fixed for 3.6 and 3.7, but not in 3.5. -- nosy: +Segev Finer ___

[issue31113] Stack overflow with large program

Manuel Krebber added the comment: I have already tried to reduce the nesting, but it still crashes. I have to admit that ~20 levels of nesting are still quite a lot. But I am surprised that so few levels of nesting already are a problem for the parser... I have attached the generated code

[issue31113] Stack overflow with large program

Stefan Behnel added the comment: Regarding the user side of the problem, you might(!) be able to work around the crash by merging nested if-conditions into and-expressions if they have no elif/else. That's also why the split into multiple files doesn't help, it's the depth of the nesting and

[issue31120] [2.7] Python 64 bit _ssl compile fails due missing buildinf_amd64.h

Changes by Zachary Ware : -- assignee: christian.heimes -> zach.ware ___ Python tracker ___

[issue31120] [2.7] Python 64 bit _ssl compile fails due missing buildinf_amd64.h

Changes by Hiren Vadalia : -- nosy: +zach.ware ___ Python tracker ___ ___

[issue31121] Unable to exit pdb when script becomes invalid

New submission from Jason R. Coombs: Similar to #16180 and possible a duplicate of #14743, if the script being run under pdb becomes invalid such as through a chdir operation, pdb will get trapped in a loop, catching its own exception. $ mkdir foo $ cat > foo/script.py import os

[issue31120] [2.7] Python 64 bit _ssl compile fails due missing buildinf_amd64.h

Changes by Hiren Vadalia : -- keywords: +patch Added file: http://bugs.python.org/file47057/openssl-1.0.2j.diff ___ Python tracker

[issue31106] os.posix_fallocate() generate exception with errno 0

Марк Коренберг added the comment: posix_fadvise() is also affected :( Fixed in this patch. -- ___ Python tracker ___

[issue31106] os.posix_fallocate() generate exception with errno 0

Марк Коренберг added the comment: All checks passed. Please merge. -- ___ Python tracker ___ ___

[issue31120] [2.7] Python 64 bit _ssl compile fails due missing buildinf_amd64.h

Hiren Vadalia added the comment: Just another update I had chat with Zach for this on core-mentors...@python.org and he suggested to supply a patch which I will submit soon. -- ___ Python tracker

[issue31120] [2.7] Python 64 bit _ssl compile fails due missing buildinf_amd64.h

Hiren Vadalia added the comment: I did some more digging into this and I found something strange: So while compiling Python, it downloads externals from http://svn.python.org/projects/external/ Above site has many version of openssl so I looked into all openssl directory and found that from

[issue31120] [2.7] Python 64 bit _ssl compile fails due missing buildinf_amd64.h

New submission from Hiren Vadalia: I am trying to compile Python 2.7.13 (https://github.com/python/cpython/tree/9c1426de7521299f70eb5483e7e25d1c2a73dbbd) in 64 bit but I am getting following error: Build started: Project: _ssl, Configuration: Release|x64 Performing Pre-Build Event... Found a

[issue31106] os.posix_fallocate() generate exception with errno 0

Марк Коренберг added the comment: https://github.com/python/cpython/pull/3000 -- ___ Python tracker ___ ___

[issue31106] os.posix_fallocate() generate exception with errno 0

Changes by Марк Коренберг : -- pull_requests: +3036 ___ Python tracker ___ ___

[issue31106] os.posix_fallocate() generate exception with errno 0

Марк Коренберг added the comment: Also, EINTR will not be caught too (!) -- ___ Python tracker ___ ___

[issue31106] os.posix_fallocate() generate exception with errno 0

Марк Коренберг added the comment: man posix_fallocate: RETURN VALUE posix_fallocate() returns zero on success, or an error number on failure. Note that errno is not set. -- ___ Python tracker

[issue23702] docs.python.org/3/howto/descriptor.html still refers to "unbound methods"

Johannes Lade added the comment: And sorry for my lousy manners. Of course I appreciate all the hard work you do! It's just frustrating when you get confused by doc. -- ___ Python tracker

[issue23702] docs.python.org/3/howto/descriptor.html still refers to "unbound methods"

Johannes Lade added the comment: This is still a problem. Can please somebody fix this? There are already enough confusing discussion full of wrong information about this topic, so it would be nice if the official documentation would get it right. Also there's multiple Issues for this. Can

[issue31107] copyreg does not properly mangle __slots__ names

Serhiy Storchaka added the comment: New changeset c4c9866064f03646c686d7e08b00aeb203c35c19 by Serhiy Storchaka (Shane Harvey) in branch 'master': bpo-31107: Fix copyreg mangled slot names calculation. (#2989) https://github.com/python/cpython/commit/c4c9866064f03646c686d7e08b00aeb203c35c19

[issue31119] Signal tripped flags need memory barriers

New submission from Nathaniel Smith: Sometimes, CPython's signal handler (signalmodule.c:signal_handler) runs in a different thread from the main thread. On Unix this is rare but it does happen (esp. for SIGCHLD), and on Windows it happens 100% of the time. It turns out that there is a subtle

[issue15988] Inconsistency in overflow error messages of integer argument

Oren Milman added the comment: How do we proceed? should I update (if needed) each of the patches I uploaded in March to eliminate commit conflicts? or can someone review them as they are now? -- ___ Python tracker

[issue30717] Add unicode grapheme cluster break algorithm

Serhiy Storchaka added the comment: The well known library for Unicode support in C++ and Java is ICU (International Components for Unicode). There is a Python wrapper [1]. This is a large complex library that covers many aspects of Unicode support. It's interface looks rather Javaic than

[issue31118] Make super() work with staticmethod by using __class__ for both arguments to super()

Changes by Serhiy Storchaka : -- nosy: +ncoghlan ___ Python tracker ___ ___

[issue31118] Make super() work with staticmethod by using __class__ for both arguments to super()

Changes by Ashwini Chaudhary : -- components: +Interpreter Core ___ Python tracker ___

[issue31118] Make super() work with staticmethod by using __class__ for both arguments to super()

New submission from Ashwini Chaudhary: >From this question I noticed that super() doesn't work with static methods >with no arguments: https://stackoverflow.com/q/45498675/846892 My question is what's the issue with using __class__ for both arguments to super() in case of static method? Or

[issue31113] Stack overflow with large program

Stefan Behnel added the comment: I've looked at the file and it contains a huge amount of deeply nested if-statements. Given that parsers and compilers are typically recursive, I can well imagine that this is a problem, and my guess is that it's most likely just the different C level stack

[issue30717] Add unicode grapheme cluster break algorithm

Stefan Behnel added the comment: Wouldn't this be a typical case where we'd expect a module to evolve and gain usage on PyPI first, before adding it to the stdlib? Searching for "grapheme" in PyPI gives some results for me. Even if they do not cover what this ticket asks for, they might give