[issue43455] pathlib mistakenly assumes os.getcwd() is a resolved path in Windows

Tzu-ping Chung added the comment: I believe this has been fixed in https://github.com/python/cpython/pull/25264 -- ___ Python tracker <https://bugs.python.org/issue43

[issue46622] Add an async variant of lru_cache for coroutines.

Tzu-ping Chung added the comment: Another thing to point out is that existing third-party solutions (both alru_cache and cached_property) only work for asyncio, and the stdlib version (as implemented now) will be an improvement. And if the position is that the improvements should only

[issue46622] Support decorating a coroutine with functools.cached_property

Change by Tzu-ping Chung : -- pull_requests: +29625 pull_request: https://github.com/python/cpython/pull/31495 ___ Python tracker <https://bugs.python.org/issue46

[issue46622] Support decorating a coroutine with functools.cached_property

Tzu-ping Chung added the comment: I agree that `print(await a.hello)` does look awkward, although I know some would disagree. (Context: I submitted this BPO after a colleague of mine at $WORK pointed out the behavioural difference between `functools` and `cached_property to me.) Personally

[issue46622] Support decorating a coroutine with functools.cached_property

Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +29476 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31314 ___ Python tracker <https://bugs.python.org/issu

[issue46738] Allow http.server to emit HTML 5

New submission from Tzu-ping Chung : Currently, a directory listing page emitted by http.parser uses the HTML 4.01 doctype. While this is perfectly fine for most uses, the server tool is sometimes used for things that require another doctype; PEP 503[1], for example, requires an HTML 5

[issue46622] Support decorating a coroutine with functools.cached_property

Tzu-ping Chung added the comment: > should not use asyncio directly but 'async def', 'await', and > `inspect.iscoroutine()` / `inspect.iscoroutinefunction()` instead. Hmm, this introduces some difficulties. Since a coroutine can only be awaited once, a new coroutine needs to be re

[issue46622] Support decorating a coroutine with functools.cached_property

New submission from Tzu-ping Chung : Currently, decorating a coroutine with cached_property would cache the coroutine itself. But this is not useful in any way since a coroutine cannot be awaited multiple times. Running this code: import asyncio import functools class

[issue45992] distutils paths are scattered between PythonXY and PythonXY-32 on WoW64

Tzu-ping Chung added the comment: They are old, but so are purelib and platlib, which were changed regardless. The problem is that distutils’s values are now half wrong and half right, neither matching pre-3.10 behaviour, nor matching post-3.10 sysconfig behaviour

[issue45992] distutils paths are scattered between PythonXY and PythonXY-32 on WoW64

New submission from Tzu-ping Chung : Should be reproducible with a 32-bit Python 3.10 running on 64-bit Windows. $ py -3.10-32 -q >>> from distutils.command.install import install :1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python

[issue43112] SOABI on Linux does not distinguish between GNU libc and musl libc

Tzu-ping Chung added the comment: Can anyone problem examples that it’s not an option to continue using the “technically incorrect” `-gnu` suffix on 3.9 and 3.10? From what I understand, te suffix technically works (as in the module will load correctly), it just fails to distinguish the ABI

[issue45035] sysconfig's posix_home scheme has different platlib value to distutils's unix_home

Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +26454 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28011 ___ Python tracker <https://bugs.python.org/issu

[issue45035] sysconfig's posix_home scheme has different platlib value to distutils's unix_home

New submission from Tzu-ping Chung : This is similar to bpo-44860, but in the other direction: $ docker run -it --rm -h=p fedora:34 bash ... [root@p /]# yum install python3 -y ... [root@p /]# type python3 python3 is hashed (/usr/bin/python3) [root@p /]# python3 -V

[issue44860] sysconfig's posix_user scheme has different platlib value to distutils's unix_user

Tzu-ping Chung added the comment: I’ve updated the linked PR to change sysconfig instead to not use sys.platlibdir when generating the posix_user scheme. This means posix_user would behave the same in 3.9+ as 3.8 and prior. -- ___ Python tracker

[issue44860] sysconfig's posix_user scheme has different platlib value to distutils's unix_user

Tzu-ping Chung added the comment: > I'm not sure if it should be used to install libraries in $HOME/.local/lib64 > rather than $HOME/.local/lib. Previously, Fedora already used > $HOME/.local/lib and $HOME/.local/lib64 is not in the sys.path. This was also briefly discussed in bp

[issue44851] Update bundled pip to 21.2.3 and setuptools to 57.4.0

Change by Tzu-ping Chung : -- pull_requests: +26168 pull_request: https://github.com/python/cpython/pull/27658 ___ Python tracker <https://bugs.python.org/issue44

[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist

Tzu-ping Chung added the comment: I think this can be closed now that the PRs are all merged? -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue44858] sysconfig's posix_user scheme has different platlib value to distutils'

Change by Tzu-ping Chung : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44858> ___ ___ Python-bugs-list

[issue44860] sysconfig's posix_user scheme has different platlib value to distutils's unix_user

Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +26149 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27655 ___ Python tracker <https://bugs.python.org/issu

[issue44860] sysconfig's posix_user scheme has different platlib value to distutils's unix_user

New submission from Tzu-ping Chung : On POSIX, the user scheme has a different 'platlib' location between distutils and sysconfig, dispite the comment claiming they should be the same. This can be reproduced on Fedora 34's stock Python 3.9: $ docker run -it --rm -h=p fedora:34 bash

[issue44858] sysconfig's posix_user scheme has different platlib value to distutils'

New submission from Tzu-ping Chung : Submitted by accident; please ignore this, sorry for the noise. (I am going to submit this issue properly.) -- resolution: -> duplicate ___ Python tracker <https://bugs.python.org/issu

[issue44858] sysconfig's posix_user scheme has different platlib value to distutils'

Change by Tzu-ping Chung : -- nosy: uranusjr priority: normal severity: normal status: open title: sysconfig's posix_user scheme has different platlib value to distutils' ___ Python tracker <https://bugs.python.org/issue44

[issue44851] Update bundled pip to 21.2.3 and setuptools to 57.4.0

Tzu-ping Chung added the comment: I was not sure what the policy is and went with the two that accepts new features hoping someone would tell me I’m wrong :p So yeah, 3.9 should be added. -- versions: +Python 3.9 ___ Python tracker <ht

[issue44851] Update bundled pip to 21.2.3 and setuptools to 57.4.0

Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +26119 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27625 ___ Python tracker <https://bugs.python.org/issu

[issue44851] Update bundled pip to 21.2.3 and setuptools to 57.4.0

New submission from Tzu-ping Chung : PR coming soon -- components: Distutils messages: 399072 nosy: dstufft, eric.araujo, uranusjr priority: normal severity: normal status: open title: Update bundled pip to 21.2.3 and setuptools to 57.4.0 versions: Python 3.10, Python 3.11

[issue43948] sysconfig's osx_framework_user puts headers in different locations from distutils

Tzu-ping Chung added the comment: Personally I am not very surprised. The scenario (installing a package to the user scheme of a macOS Framework build) is quite obscure on its own, and AFAIK no third-party package installers is currently using sysconfig. Both pip and setuptools use

[issue43948] sysconfig's osx_framework_user puts headers in different locations from distutils

Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +25641 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27093 ___ Python tracker <https://bugs.python.org/issu

[issue43948] sysconfig’s osx_framework_user puts headers in different locations from distutils

Change by Tzu-ping Chung : -- components: +macOS nosy: +ned.deily, ronaldoussoren type: -> behavior ___ Python tracker <https://bugs.python.org/issu

[issue43948] sysconfig’s osx_framework_user puts headers in different locations from distutils

New submission from Tzu-ping Chung : When built in framework mode on macOS, distutils puts user-site headers under `{userbase}/include/python{py_version_short}{abiflags}`: >>> import sys >>> print(sys.platform, sys._framework) darwin Python >>> from distutils.dis

[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment

Tzu-ping Chung added the comment: Gentle ping again :) I’ve also created a PR for this. > The Debian/Ubuntu packages have a local patch for distutils/setuptools > introducing an --install-layout option. Maybe have the same for pip? Pip already has a similar mechanism. The default

[issue43455] pathlib mistakenly assumes os.getcwd() is a resolved path in Windows

Change by Tzu-ping Chung : -- keywords: +patch nosy: +uranusjr nosy_count: 5.0 -> 6.0 pull_requests: +23574 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17716 ___ Python tracker <https://bugs.python.org/i

[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment

Tzu-ping Chung added the comment: How do we move the discussion forward? I would really want this to be included in 3.10. Assuming distutils is going to be removed in 3.12, pip would be left with an extremely short window if this has to wait for another year

[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment

Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +23429 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24644 ___ Python tracker <https://bugs.python.org/issu

[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment

Tzu-ping Chung added the comment: That would work as well (raising KeyError or ValueError if `name` is not valid?) -- ___ Python tracker <https://bugs.python.org/issue43

[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment

Tzu-ping Chung added the comment: Adding Christian to the nosy list since IIRC you said something related to this a while ago. -- nosy: +christian.heimes ___ Python tracker <https://bugs.python.org/issue43

[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment

New submission from Tzu-ping Chung : While trying to migrate pip’s internal usages of distutils to sysconfig,[1] I noticed there isn’t a way for pip to select a scheme for sysconfig.get_paths() for `pip install --target` and `pip install --user`. I tried to implement some logic to "

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Tzu-ping Chung added the comment: What would be the best channel to raise this issue to the Windows team from the outside? It does not need to be a spam campaign, but it’d be nice if we could direct the affected users somewhere instead of pypa/packaging-problems and various issue trackers

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Tzu-ping Chung added the comment: FWIW, I tweeted about this a while ago (January) and IIRC Steve said there’s plan to change that. https://twitter.com/uranusjr/status/1212450480917340160 -- nosy: +uranusjr ___ Python tracker <ht

[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist

Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +17161 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17716 ___ Python tracker <https://bugs.python.org/issu

[issue32730] Allow py launcher to launch other registered Pythons

Change by Tzu-ping Chung : -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue32730> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36383] Virtual environment sysconfig.get_path() and distutils.sysconfig.get_python_inc() reports base Python include directory

Tzu-ping Chung added the comment: I can replicate this on Linux as well. Furthormore, sysconfig.get_path('include') also returns the global path. -- components: +Library (Lib) nosy: +uranusjr title: In Windows 10 virtual environments distutils.sysconfig.get_python_inc() reports base

[issue35003] Provide an option to venv to put files in a bin/ directory on Windows

Tzu-ping Chung added the comment: > Surely "on native Windows you run venv-path\Scripts\activate[.ps1], on POSIX > you use source venv-path/bin/activate" isn't *that* hard for new users to > grok [...]? The if-Windows-X-else-Y part isn’t that hard; it’s the activate part

[issue35003] Provide an option to venv to put files in a bin/ directory on Windows

Tzu-ping Chung added the comment: There are more differences than Scripts/bin, like Windows use Lib but POSIX uses lib/pythonX.Y. IMO it’s probably better to stick with platform conventions, especially since those can be discovered with sysconfig.get_paths(expand=False). I wonder whether

[issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8

Change by Tzu-ping Chung : -- pull_requests: +16890 pull_request: https://github.com/python/cpython/pull/17410 ___ Python tracker <https://bugs.python.org/issue38

[issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8

Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +16884 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17404 ___ Python tracker <https://bugs.python.org/issu

[issue38927] venv --upgrade_deps fails on Windows

Change by Tzu-ping Chung : -- keywords: +patch pull_requests: +16883 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17403 ___ Python tracker <https://bugs.python.org/issu

[issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8

New submission from Tzu-ping Chung : The documentation says it is new in 3.8, but in reality it is not present until 3.9. https://docs.python.org/3/library/venv.html#venv.EnvBuilder.upgrade_dependencies -- assignee: docs@python components: Documentation messages: 357563 nosy: docs

[issue38927] venv --upgrade_deps fails on Windows

New submission from Tzu-ping Chung : https://github.com/python/cpython/commit/4acdbf11b1fae1af24c47413a6caa593010d1b6f EnvBuilder.upgrade_dependencies() uses `pip.exe install -U` to upgrade pip, which fails on Windows with `[WinError 5] Access is denied`. -- components: Library (Lib

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: >> not enough since it’d break `flit install --python=py` because that’s give >> you the location of py.exe, not the actual interperter. > This would be fine if you still run the process to get its sys.executable. But then I need two separate

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: To provide concrete context, the problem I’m facing is with how Flit resolves `flit install --python`: https://github.com/takluyver/flit/blob/7e65ffc7a540d76b96de0df473d3edff6f97c26c/flit/__init__.py#L18-L28 Generally the setup is to install Flit

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: I tested the following in various versions (all 64-bit) in a VM. All installations are 64-bit per-user. > py -m venv testenv > testenv\Scripts\python.exe -c "import subprocess; > print(subprocess.check_output(['python', '-c', 'import

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: > If you don't use activate.bat, but just run the venv's python directly, what > do you see? I get: > What shell are you using? Above is with cmd.exe. I get the same result as activating (i.e. shows the base interpeter). All results in cmd.ex

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: 3.6 works correctly on Windows: > py -3.6 -m venv test36 > test36\Scripts\activate.bat >>> import subprocess >>> print(subprocess.check_output(['python', '-c', 'import sys; >>> print(sys.executable)'])) b'C:\\Users\\ura

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Tzu-ping Chung added the comment: Linux works correctly (Ubuntu with self-compiled Python 3.7.5) $ python3.7 -m venv fooenv $ . fooenv/bin/activate (fooenv) $ python -c "import sys; print(sys.executable)" /home/uranusjr/fooenv/bin/python (fooenv) $ python -q >>>

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

New submission from Tzu-ping Chung : To reproduce: > py -m venv fooenv > fooenv\Scripts\activate.bat (fooenv) > python -c "import sys; print(sys.executable)" % This is correct C:\Users\uranusjr\Downloads\venvtest\Scripts\python.exe (fooenv) > python -q

[issue23706] pathlib.Path.write_text should include a newline argument

Change by Tzu-ping Chung : -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue23706> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist

Change by Tzu-ping Chung : -- title: pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not existent -> pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist ___ Pyt

[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not existent

New submission from Tzu-ping Chung : Originally from https://discuss.python.org/t/pathlib-absolute-vs-resolve/2573/4 >>> import pathlib >>> pathlib.Path().resolve() WindowsPath('C:/temp') >>> list(pathlib.Path().iterdir()) [] >>> pathlib.Pa

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

Change by Tzu-ping Chung : -- pull_requests: +11678, 11679, 11680, 11681 stage: backport needed -> patch review ___ Python tracker <https://bugs.python.org/iss

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

Change by Tzu-ping Chung : -- pull_requests: +11678, 11679, 11680 stage: backport needed -> patch review ___ Python tracker <https://bugs.python.org/iss

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

Change by Tzu-ping Chung : -- pull_requests: +11678, 11679 stage: backport needed -> patch review ___ Python tracker <https://bugs.python.org/issue1104> ___ _

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

Change by Tzu-ping Chung : -- pull_requests: +11678 stage: backport needed -> patch review ___ Python tracker <https://bugs.python.org/issue1104> ___ ___ Py

[issue35699] distutils cannot find Build Tools 2017 since 3.7.2

Tzu-ping Chung added the comment: I read a few of the logs, and all errors roots in the same place, when the test case tries to remove the tempdir during teardown/cleanup. The Windows (and other platforms not supporting directory fds) implementation of rmtree can have race conditions

[issue35699] distutils cannot find Build Tools 2017 since 3.7.2

Change by Tzu-ping Chung : -- nosy: +uranusjr ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

Tzu-ping Chung added the comment: Unfortunately it is not a viable solution. If you run the virtualenv python without activation, e.g. virtualenv --python=python3.7 foo foo/bin/python -m venv bar The VIRTUAL_ENV environment variable wouldn’t be set in this situation, but the created

[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

Tzu-ping Chung <uranu...@gmail.com> added the comment: @cosven you are correct! I made some additional observation while working on adding venv support to pew, in this thread: https://github.com/berdario/pew/pull/173. I’ll try to summarise below. The root problem is indeed virtualenv’s

[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

Tzu-ping Chung <uranu...@gmail.com> added the comment: Plot twist: the workaround does not work on Windows. $ cd SOMEDIR ; Placeholder for a valid directory. $ virtualenv env1 ... $ env\Scripts\python.exe Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1

[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

Tzu-ping Chung <uranu...@gmail.com> added the comment: Would it be possible for venv to do this automatically? Instead of using sys.executable, use import sysconfig dirname, exename = sysconfig.get_config_vars('BINDIR', 'BUILDPYTHON') to populate values in the c

[issue32577] Pip creates entry point commands in the wrong place when invoked in a venv nested in a virtualenv

Tzu-ping Chung <uranu...@gmail.com> added the comment: Yup, seems so. Closing as duplicate then. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue32577] Pip creates entry point commands in the wrong place when invoked in a venv nested in a virtualenv

New submission from Tzu-ping Chung <uranu...@gmail.com>: (I’m not sure whether this is a venv or virtualenv problem. Asking here first.) To reproduce: $ python3.6 -m virtualenv outer $ ./outer/bin/python -m venv inner $ ls inner/bin activate activate.csh activate.fish

[issue32567] Venv’s config file (pyvenv.cfg) should be compatible with ConfigParser

New submission from Tzu-ping Chung <uranu...@gmail.com>: I’m not sure if it is intended, but it seems wrong to me that pyvenv.cfg is using a format that ConfigParser does not recognise. ConfigParser requires all values be placed under a section, but pyvenv.cfg does not do that. Maybe r

[issue32442] Result of pathlib.Path.resolve() with UNC path is not very useful

Tzu-ping Chung <uranu...@gmail.com> added the comment: @Eric You’re correct, this is not the exact output. I tested the commands with a different path, but didn’t format them correctly when I convert them to use a generic example. Sorry for the confusion. @Eryk I found my prob

[issue32442] Result of pathlib.Path.resolve() with UNC path is not very useful

New submission from Tzu-ping Chung <uranu...@gmail.com>: The behaviour of os.path.abspath() and pathlib.Path.resolve() is a different when dealing with a path on a UNC share (on Windows): >>> import os, pathlib >>> path = pathlib.Path('Z:\foo') >>&g

[issue32151] -mvenv vs minor python version updates

Tzu-ping Chung <uranu...@gmail.com> added the comment: Hmm, I’m quite sure I have experience that a virtual environment breaks after a micro version upgrade on macOS, getting an “image not found” or something similar. I’m not using the official released Python, but via Homebrew, so

[issue32151] -mvenv vs minor python version updates

Tzu-ping Chung <uranu...@gmail.com> added the comment: Not sure if it’s the same thing, but I want to plug in that this can happen when you do a micro upgrade (e.g. 3.5.1 → 3.5.2) as well. This is because micro updates sometimes bump versions of dependencies (e.g. OpenS

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

Tzu-ping Chung <uranu...@gmail.com> added the comment: I made a shot to address the free() call. Hopefully this makes sense. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.pytho

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

Tzu-ping Chung <uranu...@gmail.com> added the comment: I have created a PR #4517 from the patch. Would it be better to track the malloc problem in a new issue? As for why this never caused any problems… msilib is pretty standalone, and not one of the most used modules. It is also

[issue31720] msilib.MSIError is spelled MsiError in documentation

Change by Tzu-ping Chung <uranu...@gmail.com>: -- keywords: +patch pull_requests: +3887 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue31720] msilib.MSIError is spelled MsiError in documentation

New submission from Tzu-ping Chung <uranu...@gmail.com>: The title describes it all. -- assignee: docs@python components: Documentation messages: 303877 nosy: docs@python, uranusjr priority: normal severity: normal status: open title: msilib.MSIError is spelled MsiError in documen

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

Change by Tzu-ping Chung <uranu...@gmail.com>: -- nosy: +uranusjr ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue1104> ___ __

[issue31694] Running Windows installer with LauncherOnly=1 should not register the version as installed

Tzu-ping Chung <uranu...@gmail.com> added the comment: The “this product is already installed” error is a mistake on my part. I was actually using 3.6.3 (released literally during I was testing this!) to install the launcher, and using 3.6.2 afterwards, hence the error message (bec

[issue31694] Running Windows installer with LauncherOnly=1 should not register the version as installed

New submission from Tzu-ping Chung <uranu...@gmail.com>: After running python-3.6.2-amd64.exe /quiet LauncherOnly=1 Python 3.6.2 is registered as installed, even though nothing is actually installed. Running the installer again at this point shows an error indicating “this p

[issue25312] Cryptic error message if incorrect spec is set on a callable mock

New submission from Tzu-ping Chung: >>> from unittest import mock >>> >>> class Foo: ... def __init__(self, val): ... pass ... def func(self): ... pass ... >>> class FooMock(mock.Mock): ... def _get_child_mock(self, **kwargs): .