[issue38343] Version name in PC/layout read incorrectly for RC

Change by miss-islington : -- pull_requests: +16119 pull_request: https://github.com/python/cpython/pull/16528 ___ Python tracker ___

[issue38343] Version name in PC/layout read incorrectly for RC

Steve Dower added the comment: New changeset b9a8b8296cd7be22f8b5bf92af686a788c47c7bf by Steve Dower in branch 'master': bpo-38343: Fixes version handling for nuget packages (GH-16527) https://github.com/python/cpython/commit/b9a8b8296cd7be22f8b5bf92af686a788c47c7bf --

[issue38343] Version name in PC/layout read incorrectly for RC

Change by Steve Dower : -- nosy: +lukasz.langa ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38187] test.test_tools.test_c_analyzer fails in refleak mode

Change by Eric Snow : -- status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38343] Version name in PC/layout read incorrectly for RC

Change by Steve Dower : -- keywords: +patch pull_requests: +16118 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/16527 ___ Python tracker

[issue38343] Version name in PC/layout read incorrectly for RC

Steve Dower added the comment: I already republished correctly-versioned files and unlisted the wrong ones (as well as contacting support to see whether they can delete them completely so they don't impact the final release). The change above fixes the issue. It will need cherry-picking for

[issue18309] Make python slightly more relocatable

Mathias Fröhlich added the comment: Ok, so far. But what shall I do now? It would be nice that python is a bit smarter in finding its increasing important module files when being embedded into an application. Anybody out there who wants to look at that contribution? best Mathias --

[issue38313] Crash/No start

Zachary Ware added the comment: Feel free to reopen if you can answer the questions in my previous message. -- resolution: -> works for me stage: -> resolved status: pending -> closed ___ Python tracker

[issue38331] Exec not recognizing global variables inside function

Ronald Oussoren added the comment: I don't think this is a bug. def func(): print(var) This captures the globals at the time of definition, that is "global" references are resolved using the func.__globals__ attribute which is the globals dictionary at the time the function is created

[issue36470] dataclasses.replace raises an exception if InitVar with default argument is not provided.

Change by Eric V. Smith : -- assignee: -> eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37096] Add large-file tests for modules using sendfile(2)

Charalampos Stratakis added the comment: It seems that the -uall argument is passed to regrtest invocation for the buildbot run [0] which invokes the largefile tests (including all the resource intensive tests). However when configure is run you can see: checking whether to enable large

[issue38333] add type signatures to library function docs

Guido van Rossum added the comment: I'm sorry, but that's unacceptable. On Mon, Sep 30, 2019 at 23:42 Vedran Čačić wrote: > > Vedran Čačić added the comment: > > > Many docs are ... vague about types. > > ... and I consider that a feature. At least if you do that, make an > explicit

[issue38341] Add SMTPNotSupportedError in the exports of smtplib

New submission from Norman Denayer : Long story short: smtplib.SMTPNotSupportedError seems the only exception not present in __all__ variable exposed by smtplib.py Context: I currently face an issue running mypy on one of my module: ...tools/email.py:46: error: Module has no attribute

[issue37096] Add large-file tests for modules using sendfile(2)

Giampaolo Rodola' added the comment: Sorry about that. I'm attaching a patch which skips those tests if there's not enough free disk space. If you confirm it works I'll make a PR. -- Added file: https://bugs.python.org/file48636/disk-space.patch

[issue37096] Add large-file tests for modules using sendfile(2)

STINNER Victor added the comment: Should we decorate the new files with @requires('largefile', '...')? Documentation: largefile - It is okay to run some test that may create huge files. These tests can take a long time and may consume >2 GiB of disk space

[issue37424] subprocess.run timeout does not function if shell=True and capture_output=True

STINNER Victor added the comment: > I'm still seeing hangs with subprocess.run() in Python 3.7.4 That's not surprising, the fix has been pushed at 2019-09-11. Python 3.7.5 will include the fix and it will be released soon: https://www.python.org/dev/peps/pep-0537/ --

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

Tim Peters added the comment: Neil, about this comment: # - ct is not yet trash (it actually is but the GC doesn't know because of # the missing tp_traverse method). I believe gc should know ct is trash. ct is in the cf list, and the latter does have tp_traverse. What gc won't know

[issue37096] Add large-file tests for modules using sendfile(2)

STINNER Victor added the comment: > checking whether to enable large file support... no That's only at the C level to decide how to pass a file position. It's unrelated to the regrtest "largefile" resource. -- ___ Python tracker

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

Neil Schemenauer added the comment: Łukasz, is there some reason you removed old versions (2.7, 3.6, etc)? The bug is present on those versions of Python and it should be trivial to backport the fix. If those branches are maintained, I think we should fix it. Attached is a small test

[issue38341] Add SMTPNotSupportedError in the exports of smtplib

Change by Roundup Robot : -- keywords: +patch pull_requests: +16116 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16525 ___ Python tracker ___

[issue37424] subprocess.run timeout does not function if shell=True and capture_output=True

Tony Cappellini added the comment: I'm still seeing hangs with subprocess.run() in Python 3.7.4 Unfortunately, it involves talking to an NVME SSD on Linux, so I cannot easily submit code to duplicate it. -- nosy: +cappy ___ Python tracker

[issue37424] subprocess.run timeout does not function if shell=True and capture_output=True

Tony Cappellini added the comment: Using Python 3.7.4, I'm calling subprocess.run() with the following arguments. .run() still hangs even though a timeout is being passed in. subprocess.run(cmd_list, stdout=subprocess.PIPE,

<    1   2