[issue34095] [2.7] test_idle fails with: /usr/bin/xvfb-run: line 181: 3617 Segmentation fault

Chih-Hsuan Yen added the comment: Here is partial backtrace from commit 1d26c72e6a9c5b28b27c158f2f196217707dbb0f: #0 0x76763197 in GetTkFontAttributes (faPtr=faPtr@entry=0x55cd91e8, ftFont=) at /usr/src/debug/tk8.6.8/unix/../unix/tkUnixRFont.c:167 #1 0x767639fa in In

[issue34956] _tkinter built on macOS 10.14 does not link to Tcl and Tk in /Library/Frameworks

Ned Deily added the comment: macOS 10.14 appears to have introduced some subtle differences in the search order for finding header files and/or frameworks and libraries. I'm not 100% sure I understand completely what has changed but I'm confident that the workaround outlined below should ge

[issue21880] IDLE: Ability to run 3rd party code checkers

Change by Tal Einat : -- pull_requests: +9185 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue21880] IDLE: Ability to run 3rd party code checkers

Tal Einat added the comment: See PR9802. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue34956] _tkinter built on macOS 10.14 does not link to Tcl and Tk in /Library/Frameworks

Ned Deily added the comment: Correction: in the original second paragraph, the fourth sentence obviously has the case backwards. It should read: "When using a *Command Line Tools installation (no Xcode)* in previous releases of macOS, I believe it was the case that essentially the system ro

[issue34954] Getting an email's subject is error-prone

Alex Corcoles added the comment: Well, I think that having to choose the "HTTP" policy to get a message subject's without newlines goes against the expectations of anyone who is not well knowledgeable of email. It's not very easy to deduct that, out of all the available policies, HTTP is the

[issue34576] [EASY doc] http.server, SimpleHTTPServer: warn users on security

STINNER Victor added the comment: The render is surprising: it looks like the full documentation is part of the § Security Considerations: https://docs.python.org/dev/library/http.server.html#security-considerations I suggest to add a new title for the rest of the documentation. --

[issue34957] Segementation faults on ARM and ARM64

New submission from Stefan Rink : When trying to run dask distributed on ARM you will end with a segmentation fault on multiple in multiple tests; Works on AMD64 but does not work on ARM or AARCH64 and results in a Signal 11. Example; # python Python 3.6.6 (default, Sep 29 2018, 05:50:41) [G

[issue34957] Segementation faults on ARM and ARM64

STINNER Victor added the comment: Is it possible that this bug is a duplicate of bpo-29804? Would you be able to test Python 3.7.1RC1? Sadly, this issue says "OK, PR 1559 (in 3.7.0) for Issue30353 has been backported to 3.6 in PR 5954 for release in 3.6.5". I know that FreeBSD uses our bund

[issue32153] mock.create_autospec fails if an attribute is a partial function

Karthikeyan Singaravelan added the comment: I think the original error has been fixed with issue28919 where the attribute errors are ignored while copying the functions as suggested by Anthony in solution 2. So can this issue be closed as outdated to reopen a new one for using update_wrapper

[issue34957] Segementation faults on ARM and ARM64

Stefan Rink added the comment: * (re)installed libffi but it was already version 3.2.1. * Currently compiling python3.7 on both ARM and AARCH64 to test them. This may take a while because I need to install dask again for 3.7 to test.. Didn't try this on Linux ARM yet so I'll also try that. P

[issue32153] mock.create_autospec fails if an attribute is a partial function

Berker Peksag added the comment: Yes, it would be great if we could convert the snippet in msg307115 to a test case before closing this issue. 3.6 still has this bug, but since we are pretty close to the end of its bugfix maintenance period, we can skip it. -- versions: -Python 3.6

[issue2142] difflib.unified_diff(...) produces invalid patches

Change by Xiao Di Guan : -- nosy: +puxlit ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue29427] Option to skip padding for base64 urlsafe encoding/decoding

Change by Xiao Di Guan : -- nosy: +puxlit ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue29427] Option to skip padding for base64 urlsafe encoding/decoding

Change by Mayank Asthana : -- nosy: +masthana ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue34958] urllib.error.HTTPError.fp is not closed when error is finalized on Windows

New submission from Xiao Di Guan : Following changes introduced in bpo-15002, HTTPError closes its fp when GCed via tempfile._TemporaryFileCloser's finalizer. However, the current implementation of _TemporaryFileCloser only defines __del__ for non-NT platforms. Assuming HTTPError.fp is part

[issue34959] Are the tests optional on travis?

New submission from Stéphane Wirtel : In the config of Travis, we can see there is a OPTIONAL=true env var for the tests at line 72: https://github.com/python/cpython/blob/master/.travis.yml#L72 If I read the doc, normally the tests can crash and this is not a problem? Is it right, because I

[issue32696] Fix pickling exceptions with multiple arguments

Change by Orivej Desh : -- nosy: +orivej ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__

Change by Orivej Desh : -- nosy: +orivej ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue34959] Are the tests optional on travis?

Stéphane Wirtel added the comment: this issue is useless :/ -- stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue34959] Are the tests optional on travis?

Change by Stéphane Wirtel : -- resolution: -> rejected ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue34957] Segementation faults on ARM and ARM64

Stefan Rink added the comment: On ARM32 it still crashed but on the ARM64 upgrade to 3.7 helped! Need to do some more testing but it looks like it's working now. # python3.7 Python 3.7.0 (default, Sep 29 2018, 05:58:20) [Clang 6.0.1 (tags/RELEASE_601/final 335540)] on freebsd12 Type "help", "

[issue34095] [2.7] test_idle fails with: /usr/bin/xvfb-run: line 181: 3617 Segmentation fault

Terry J. Reedy added the comment: Additional notes: I am puzzled that test_idle output starts with test_io, as that is alphabetically in the middle of the files in idle_test/. There are 2 independent 'test_io' modules: test/test_io, which tests the io module, and idlelib/test_idle/test_io,

[issue34954] Getting an email's subject is error-prone

R. David Murray added the comment: Can you demonstrate that policy.default and policy.SMTP produce a subject with newlines? If they do, that is a serious bug. Please don't reopen the issue. I'll reopen it if you convince me there is a bug :) The statement you suggest we add is not appropr

[issue34954] Getting an email's subject is error-prone

R. David Murray added the comment: I'm guessing you got confused by the fact that the HTTP policy doesn't *add* new lines when *serializing*. If you can point to the part of the docs you read that produced that confusion, maybe we can improve it. --

[issue34576] [EASY doc] http.server, SimpleHTTPServer: warn users on security

Senthil Kumaran added the comment: @Victor - Surprising. Thanks for noticing this. I will fix it shortly. -- ___ Python tracker ___ ___

[issue34954] Getting an email's subject is error-prone

Alex Corcoles added the comment: Duh, I'm an idiot, I only tested policy.HTTP and *NOT* supplying a policy (which I believed was equivalent to using policy.default). policy.default and policy.SMTP do indeed produce a newline-less subject indeed. I only tested policy.HTTP because the docs talk

[issue34957] Segementation faults on ARM and ARM64

Stefan Rink added the comment: Upgrade to 3.7 fixed the main problem for me, or at least on the hardware/arch I use. -- On ARM32 it still failed but I don't have debugging symbols there so not so easy to troubleshoot further -- -- resolution: -> works for me __

[issue34811] test_gdb fails with latest gdb

STINNER Victor added the comment: Update: I reproduced the bug but then I was unable to go futher, I was blocked by gdb which decided to crash in Fedora rawhide (gdb 8.2.50.20181006-4.fc30) :-/ -- ___ Python tracker

[issue34957] Segementation faults on ARM and ARM64

STINNER Victor added the comment: > Upgrade to 3.7 fixed the main problem for me, or at least on the > hardware/arch I use. For Python, we should try to identify the required backport, or upgrade libffi in Python 3.6. But I'm scared by Modules/_ctypes/libffi/ since it's unclear to me if we

[issue34957] Segementation faults on ARM and ARM64

Zachary Ware added the comment: IIRC, the default in 3.6 is to use `--with-system-ffi` if available on all platforms but macOS, falling back to the bundled copy only if a system copy can't be found; 3.7 removes the bundled copy. Also, the version bundled with 3.6 is v3.2.1. Note though tha

[issue2142] difflib.unified_diff(...) produces invalid patches

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue34960] python-config bad ldflags on macOS

New submission from Simon Wells : if you didn't build python as a framework it adds sysconfig.get_config_vars('LINKFORSHARED') when you run 'python-config --ldflags' this resolves to >>> sysconfig.get_config_var('LINKFORSHARED') '-Wl,-stack_size,100 -framework CoreFoundation /usr/local/

[issue34960] python-config bad ldflags on macOS

Ned Deily added the comment: Sorry, I can't reproduce that behavior. What's more, that LINKFORSHARED value does not appear to be correct. Have you tried doing a build from a clean build dicectory while rerunning ./configure? What does your ./configure look like and do have any relevant en

[issue34961] Global scoping when shadowing local names in class definitions

New submission from multun : Hello, >>> a="global" >>> def func(a): ... class wtf(): ... a=a ... return wtf ... >>> func("local").a 'global' >>> def func2(a): ... class wtf(): ... b=a ... return wtf ... >>> func2("local").b 'local' Is this behavior le

[issue34960] python-config bad ldflags on macOS

Simon Wells added the comment: with a fresh 3.7.0 download ./configure --prefix=... --enable-shared make -j5 make install path/to/python3-config --ldflags -lpython3.7m -ldl -framework CoreFoundation -Wl,-stack_size,100 -framework CoreFoundation -- __

[issue34960] python-config bad ldflags on macOS

Ned Deily added the comment: Oh, you didn't mention --enable-shared! But still it's not clear to me what problem your last results shows. The value of python3-config --ldflags looks fine (ignore the repeated -framework CoreFoundation). Are you still getting the "ld: -stack_size option can

[issue34960] python-config bad ldflags on macOS

Simon Wells added the comment: ah ok, sorry i wasn't clear at first, the issue isn't when building python its when building a library which depends on python in this case libxml2, which when given the --enable-python stuff uses "PYTHON_LIBS=`python$PYTHON_VERSION-config --ldflags`" and there

[issue34960] macOS builds expose stack_size option in LINKEDFOORSHARED and pyconfig

Ned Deily added the comment: OK, now I finally get it, thanks, my fault. Yes, we probably shouldn't be passing stack_size through to applications trying to embed Python in LINkFORSHARED and pyconfig. That's an area that we don't test very well nor have tests for, AFAIK. Would it possible

[issue34960] macOS builds expose stack_size option in LINKEDFOORSHARED and pyconfig

Simon Wells added the comment: oh the rabbit hole... as i have other builds of python3.7 on my system i wanted to ensure it used the correct python and python-config (python 3.7 was built and installed into $HOME/Projects/python/inst/) as such its a rather convoluted configure command for l

[issue34962] make doctest does not pass :/

New submission from Stéphane Wirtel : make -C Doc/ doctest does not pass the tests. -- messages: 327553 nosy: matrixise priority: normal severity: normal status: open title: make doctest does not pass :/ versions: Python 3.8 ___ Python tracker

[issue34939] Possibly spurious SyntaxError: annotated name can't be global

Ivan Levkivskyi added the comment: I think we can just go ahead and allow this. If there is a volunteer, please go ahead, otherwise I will try to find time for this myself. -- ___ Python tracker ___

[issue34962] make doctest does not pass :/

Change by Stéphane Wirtel : -- keywords: +patch pull_requests: +9186 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-l

[issue27741] datetime.datetime.strptime functionality description incorrect

Gus Goulart added the comment: It is true that time.srtptime() does not return microseconds, but as the documentation suggests, it will return the microseconds after you wrap it up with datetime(). I have attached a walkthrough of how I see that section of the docs. Please let me know if you

[issue27741] datetime.datetime.strptime functionality description incorrect

Change by Gus Goulart : -- nosy: +taleinat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue27741] datetime.datetime.strptime functionality description incorrect

Change by Ned Deily : -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue34956] _tkinter built on macOS 10.14 does not link to Tcl and Tk in /Library/Frameworks

Kevin Walzer added the comment: Thank you, this helped. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue34893] Add 2to3 fixer to change send and recv methods of socket object.

Pranav Devarakonda added the comment: I have added a final condition that converts the arguments passed to bytes only if the type of object is socket and the method is send() in the generated code. All the other conversions still function as expected. -- Added file: https://bugs.pyth

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

New submission from Alexander Böhn : When creating a new type with `typing.NewType(…)` the result is a function defined on-the-fly with no reasonable `__repr__` definition – the string representation of the type looks something like e.g. “.new_type at 0x108ae6950>” which isn’t very useful or a

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Change by Alexander Böhn : -- keywords: +patch pull_requests: +9187 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue34748] Incorrect HTML link in functools.partial

Change by Roundup Robot : -- keywords: +patch pull_requests: +9188 stage: needs patch -> patch review ___ Python tracker ___ ___ Pyt

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Change by Alexander Böhn : -- components: +Library (Lib) -Extension Modules ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Change by Alexander Böhn : -- versions: +Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue34748] Incorrect HTML link in functools.partial

Andrei Petre added the comment: Hi, I've also looked into this and I've added a patch addressing both updates (mentioned by xitop and xtreak). -- nosy: +andreip ___ Python tracker __

[issue18114] Update PyImport_ImportFrozenModuleObject() to set __package__

Andrei Petre added the comment: Hi, is this still relevant? I see the file has changed quite a bit. -- nosy: +andreip ___ Python tracker ___ __

[issue34547] Wsgiref server does not handle closed connections gracefully

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue34696] PyByteArray_FromObject() has undocumented (and untested) behavior

Serhiy Storchaka added the comment: See also issue26759. -- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka ___ Python tracker ___ _

[issue34547] Wsgiref server does not handle closed connections gracefully

Karthikeyan Singaravelan added the comment: Thanks for the report and PR. I think this is the same as issue27682. I noticed the same during running `make serve` locally for documentation and it's worth fixing. I am just wondering if it makes sense to fix the TypeError and AttributeError too.

[issue27682] wsgiref: Windows Error 10053, ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software in your host machine

Karthikeyan Singaravelan added the comment: I think this is an issue with wsgiref handling client closure rather than a Windows/Django bug. I saw this sporadically but not consistently while running `make serve` to serve the docs which uses wsgiref simple server to serve docs on my Mac OS. R

[issue34926] Allow querying a Path's mime-type

Karthikeyan Singaravelan added the comment: As part of triaging, I am closing this since this was merged with doc changes and there was no back port done since it's an enhancement. Antoine, feel free to reopen this if there are any changes left. Thanks everybody for the feedback and review.