[issue44406] Divergent sys.prefix behavior causes `python -m build` command to fail when in virtual environment

2021-06-13 Thread Paul Moore
Paul Moore added the comment: I don't inderstand what "discrepancy" you mean here. The documentation you quote explains the behaviour, and I don't see the problem. If build is failing, why do you not think that is a bug in build? I can only see one call to venv.EnvBuilder in th

[issue43993] Update bundled pip to 21.1.1

2021-05-01 Thread Paul Moore
Paul Moore added the comment: New changeset 6034c4aa58fe7257d39b53c77944393700c66396 by Stéphane Bidoul in branch '3.8': [3.8] bpo-43993: Update vendored pip to 21.1.1 (GH-25761). (GH-25783) https://github.com/python/cpython/commit/6034c4aa58fe7257d39b53c77944393700c66396

[issue43993] Update bundled pip to 21.1.1

2021-05-01 Thread Paul Moore
Paul Moore added the comment: New changeset af1e06c62f3958082c4b409e771f291d12479b3d by Stéphane Bidoul in branch '3.9': [3.9] bpo-43993: Update vendored pip to 21.1.1 (GH-25761). (GH-25782) https://github.com/python/cpython/commit/af1e06c62f3958082c4b409e771f291d12479b3d

[issue43993] Update bundled pip to 21.1.1

2021-05-01 Thread Paul Moore
Paul Moore added the comment: New changeset bf99b7151663905fd5e71efe45184dc8fffc3236 by Stéphane Bidoul in branch 'master': bpo-43993: Update vendored pip to 21.1.1 (GH-25761) https://github.com/python/cpython/commit/bf99b7151663905fd5e71efe45184dc8fffc3236 -- nosy: +paul.moore

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

2021-04-30 Thread Paul Moore
Paul Moore added the comment: Eryk, thank you for clarifying. I apologise - I got bogged down somewhere in the middle of the discussion on reimplementing bits of the CRT (your posts are so information-dense that my usual habit of skimming breaks down - that's not a complaint, though

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

2021-04-30 Thread Paul Moore
Paul Moore added the comment: Looking at the various comments, I think we have 5 votes for deleting on CM exit when used as a CM, and no change in behaviour otherwise (me, Zachary, Ethan, Jason and Steve). Steve also wants O_TEMPORARY to be removed, which doesn't seem controversial among

[issue41282] Deprecate and remove distutils

2021-04-29 Thread Paul Moore
Paul Moore added the comment: I'd suggest also posting it on the Packaging discourse, to get feedback from other distro maintainers. -- ___ Python tracker <https://bugs.python.org/issue41

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

2021-04-28 Thread Paul Moore
Paul Moore added the comment: To be explicit, I'm +1 on breaking backward compatibility in the minor form described by Ethan: if NamedTemporaryFile is used as a context manager, the file is closed *on context manager exit* and *not* when the file is closed. Breaking compatibility is allowed

[issue43958] Importlib.metadata docs claim PackagePath is a Path subclass

2021-04-27 Thread Paul Moore
Change by Paul Moore : -- keywords: +patch pull_requests: +24358 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25669 ___ Python tracker <https://bugs.python.org/issu

[issue43958] Importlib.metadata docs claim PackagePath is a Path subclass

2021-04-27 Thread Paul Moore
New submission from Paul Moore : The importlib.metadata documentation states that the PackagePath class is "a pathlib.Path derived object". This isn't true - it's a PurePath subclass, and in particular it does not have a resolve() method. In fact, it has an undocumented cus

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

2021-04-27 Thread Paul Moore
Paul Moore added the comment: New changeset d92513390a1a0da781bb08c284136f4d7abea36d by Tzu-ping Chung in branch 'master': bpo-43312: Functions returning default and preferred sysconfig schemes (GH-24644) https://github.com/python/cpython/commit/d92513390a1a0da781bb08c284136f4d7abea36d

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

2021-04-24 Thread Paul Moore
Paul Moore added the comment: New changeset fc82f3f8fb36f88a4e7238a463812c2916bd4db0 by Stéphane Bidoul in branch '3.8': [3.8] bpo-43930: Update bundled pip to 21.1 and setuptools to 56.0.0 (GH-25576) (GH-25579) https://github.com/python/cpython/commit

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

2021-04-24 Thread Paul Moore
Paul Moore added the comment: New changeset d962b00fcffa9070acdca850753f254828caa1d7 by Stéphane Bidoul in branch '3.9': [3.9] bpo-43930: Update bundled pip to 21.1 and setuptools to 56.0.0 (GH-25578) https://github.com/python/cpython/commit/d962b00fcffa9070acdca850753f254828caa1d7

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

2021-04-24 Thread Paul Moore
Paul Moore added the comment: New changeset 196983563d05e32d2dcf217e955a919f9e0c25e1 by Stéphane Bidoul in branch 'master': bpo-43930: Update bundled pip to 21.1 and setuptools to 56.0.0 (GH-25576) https://github.com/python/cpython/commit/196983563d05e32d2dcf217e955a919f9e0c25e1

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

2021-04-12 Thread Paul Moore
Paul Moore added the comment: Sorry - I'm maybe making an unwarranted assumption. If simply removing "delete on close" behaviour in the CM case is acceptable, then I'm 100% in favour of that. I'd assumed that it was somehow unacceptable, but you're right, and it's not cle

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

2021-04-12 Thread Paul Moore
Paul Moore added the comment: There's a lot of technical discussion of implementation details here, but not much about use cases. IMO, what's more important is whether NamedTemporaryFile is *useful* to people, and what they want to use it *for*. Working out how to implement it can come

[issue43697] Importlib documentation does not cover how meta path finders should handle namespace packages

2021-04-01 Thread Paul Moore
Paul Moore added the comment: > if they return a spec they can, if they don't then they can't What I've never really got clear in my mind is how dotted names get handled. But that's probably just a matter of needing to experiment a bit (I don't think it's particularly complicated, I j

[issue43697] Importlib documentation does not cover how meta path finders should handle namespace packages

2021-04-01 Thread Paul Moore
Paul Moore added the comment: OK, cool. That might be worth explaining somewhere in the docs (although I don't really know where, as I'm not sure where namespace packages are documented, either :-)) I'm not at all sure what would happen if we have meta path finders A and B

[issue43697] Importlib documentation does not cover how meta path finders should handle namespace packages

2021-04-01 Thread Paul Moore
New submission from Paul Moore : I am trying to write a meta path finder that "redirects" module loads to a different part of the filesystem. There's not much information in the importlib documentation, but PEP 451 says "find_spec() must return a spec with "loader&

[issue29399] python3.dll export forwarders not resolved in all situations due to missing python3?.dll dependency and DLL search path behavior

2021-02-25 Thread Paul Moore
Paul Moore added the comment: No, because I want to work with whatever version of Python the user puts there. Yes, I could search for "python3*.dll" and load the one I find, but I'm writing this in C, and I get a migraine whenever I have to write more than about 15 lines

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

2021-02-02 Thread Paul Moore
Paul Moore added the comment: That's specifically the ensurepip PR, which is now outdated since pip 21.0.1 is in master. But for this bug report, Steve said "I still consider the changes a release blocking regression, but if it's not blocking ensurepip then I guess the updated package

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

2021-02-02 Thread Paul Moore
Paul Moore added the comment: It can be closed. -- ___ Python tracker <https://bugs.python.org/issue41490> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

2021-02-01 Thread Paul Moore
Paul Moore added the comment: I'm not sure why, but the PR to update the bundled pip to 21.0.1 (and setuptools to 52.0.0) merged cleanly, so this may be obsolete now. -- ___ Python tracker <https://bugs.python.org/issue41

[issue43077] Update bundled pip to 21.0.1 and setuptools to 52.0.0

2021-01-30 Thread Paul Moore
Change by Paul Moore : -- pull_requests: +23203 pull_request: https://github.com/python/cpython/pull/24388 ___ Python tracker <https://bugs.python.org/issue43

[issue43077] Update bundled pip to 21.0.1 and setuptools to 52.0.0

2021-01-30 Thread Paul Moore
Change by Paul Moore : -- keywords: +patch pull_requests: +23202 pull_request: https://github.com/python/cpython/pull/24387 ___ Python tracker <https://bugs.python.org/issue43

[issue43077] Update bundled pip to 21.0.1 and setuptools to 52.0.0

2021-01-30 Thread Paul Moore
Paul Moore added the comment: New changeset 4d11ecbb5ed78e6259ee27289c7638aad795f473 by Paul Moore in branch 'master': bpo-43077: Update bundled pip to 21.0.1 and setuptools to 52.0.0 (GH-24386) https://github.com/python/cpython/commit/4d11ecbb5ed78e6259ee27289c7638aad795f473

[issue43077] Update bundled pip to 21.0.1 and setuptools to 52.0.0

2021-01-30 Thread Paul Moore
Change by Paul Moore : -- assignee: -> paul.moore nosy: +Marcus.Smith, dstufft, ncoghlan, pradyunsg stage: -> patch review ___ Python tracker <https://bugs.python.org/i

[issue43077] Update bundled pip to 21.0.1 and setuptools to 52.0.0

2021-01-30 Thread Paul Moore
New submission from Paul Moore : I've just released pip 21.0.1, so this updates the bundled copy (as well as updating setuptools). I assume this should be backported to 3.8 and 3.9. -- components: Library (Lib) messages: 385986 nosy: paul.moore priority: normal pull_requests: 23201

[issue43022] Unable to dynamically load functions from python3.dll

2021-01-25 Thread Paul Moore
Paul Moore added the comment: > PathAllocCombine() is Windows 8+, so sample code that uses it would only be > for Python 3.9+. Yeah, I'm probably going to remove that. I mainly used it because I'm *so* spoiled by Python, writing code in C where I have to actually implement stuff for

[issue43022] Unable to dynamically load functions from python3.dll

2021-01-25 Thread Paul Moore
Paul Moore added the comment: > I think here you're in a very small minority who could get away with this, > and so I'd hesitate to make it sound like the recommended approach. Well, the evidence here is that maybe even I shouldn't be doing this :-) > What I'd actually recommend (o

[issue43022] Unable to dynamically load functions from python3.dll

2021-01-25 Thread Paul Moore
Paul Moore added the comment: Confirmed. The following code works as I want: Py_Main_t get_pymain(wchar_t *base_dir) { wchar_t *dll_path; HRESULT hr = PathAllocCombine( base_dir, L"python\\python3.dll", PATHCCH_ALLOW_LONG_PATHS, _path ); if (

[issue43022] Unable to dynamically load functions from python3.dll

2021-01-25 Thread Paul Moore
Paul Moore added the comment: Thanks, I'll give that a try. It sounds like I'm just using the APIs incorrectly, which would be good (in the sense that I can do what I wanted, I just didn't know how ;-)) I wonder whether it would be worth having a section in the docs somewhere explaining

[issue43022] Unable to dynamically load functions from python3.dll

2021-01-25 Thread Paul Moore
Paul Moore added the comment: Thinking about what you said, "the loader waits to load it until first accessed via GetProcAddress()" did you mean by that, that the following code should work: h = LoadLibraryW(L"some/path/to/python3.dll") py_main = GetPro

[issue43022] Unable to dynamically load functions from python3.dll

2021-01-25 Thread Paul Moore
Paul Moore added the comment: So I need to dynamically load *both* python3.dll and python39.dll, but if I do that I can get the functions from python3.dll? What's the point in doing that? Surely I might as well just load python39.dll and get the functions from there, in that case. I hoped

[issue43022] Unable to dynamically load functions from python3.dll

2021-01-25 Thread Paul Moore
New submission from Paul Moore : I am writing a small application using the embedded distribution to run a script supplied by the user. The requirements are very simple, so all I need to do is set up argv and call Py_Main. I'm trying to load the Py_Main function dynamically (for flexibility

[issue42902] a python embedded program may load "C:\Lib\os.py" on windows system

2021-01-12 Thread Paul Moore
Paul Moore added the comment: I thought that *all* versions of Python located the standard library by searching for os.py... -- ___ Python tracker <https://bugs.python.org/issue42

[issue42863] Python venv inconsistent folder structure on windows

2021-01-08 Thread Paul Moore
Paul Moore added the comment: Many tools hard code the "if windows then 'Scripts' else 'bin'" logic. They will simply fail to work with environments that don't have that layout. Yes, they probably should use sysconfig, but many don't (and sometimes for arguably good reasons, f

[issue42855] pathlib.exists on Windows raises an exception on URL like/bad input

2021-01-07 Thread Paul Moore
Paul Moore added the comment: So I guess the key question then is whether Path.exists() should trap exceptions and interpret them as "does not exist" (on all platforms, although it looks like the null character case in Unix has now been fixed). Which doesn't seem unreasonabl

[issue42855] pathlib.exists on Windows raises an exception on URL like/bad input

2021-01-07 Thread Paul Moore
Paul Moore added the comment: "http:" isn't a valid drive letter, I'd imagine. -- ___ Python tracker <https://bugs.python.org/issue42855> ___ ___

[issue42855] pathlib.exists on Windows raises an exception on URL like/bad input

2021-01-07 Thread Paul Moore
Paul Moore added the comment: It's an invalid filename so it raises an exception. You can get the same on Unix by using an invalid filename (embedded null): >>> from pathlib import Path >>> Path("/usr/\0").exists() Traceback (most recent call last):   File "

[issue42683] asyncio should handle keyboard interrupt while the event loop is running

2020-12-19 Thread Paul Moore
Change by Paul Moore : -- nosy: +njs ___ Python tracker <https://bugs.python.org/issue42683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue42683] asyncio should handle keyboard interrupt while the event loop is running

2020-12-19 Thread Paul Moore
New submission from Paul Moore : See the comment on Discourse here: https://discuss.python.org/t/feeding-data-generated-via-asyncio-into-a-synchronous-main-loop/5436/28 (and the thread leading up to this comment). In the thread, @njs states that if the user hits Ctrl-C while the asyncio

[issue42518] Error Message

2020-12-01 Thread Paul Moore
Paul Moore added the comment: You need to learn about chained comparisons in Python. This is not a bug. Please stop reopening it. -- status: open -> closed ___ Python tracker <https://bugs.python.org/issu

[issue42293] Installation of pyinstaller in Windows fails with utf8 error

2020-11-14 Thread Paul Moore
Paul Moore added the comment: I've raised https://github.com/pypa/pip/issues/9135 for this. -- ___ Python tracker <https://bugs.python.org/issue42293> ___ ___

[issue42293] Installation of pyinstaller in Windows fails with utf8 error

2020-11-14 Thread Paul Moore
Paul Moore added the comment: Erik is correct, this is a pip bug. Please raise an issue on the pip tracker linking to this issue and we can fix it. -- ___ Python tracker <https://bugs.python.org/issue42

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-20 Thread Paul Moore
Paul Moore added the comment: New changeset 5ab27cc518f614a0b954ff3eb125290f264242d5 by Paul Moore in branch 'master': bpo-42041: Clarify how subprocess searches for the executable (GH-22715) https://github.com/python/cpython/commit/5ab27cc518f614a0b954ff3eb125290f264242d5

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-19 Thread Paul Moore
Paul Moore added the comment: I like that, I've updated the PR accordingly. -- ___ Python tracker <https://bugs.python.org/issue42041> ___ ___ Python-bugs-list m

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-19 Thread Paul Moore
Paul Moore added the comment: My biggest concern with the suggested wording (which in broad terms looks OK to me) is that it reintroduces the issue with the redirector. By specifically saying that the behaviour in `CreateProcess` applies, we lead the user to the statement that the search

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-18 Thread Paul Moore
Paul Moore added the comment: Exactly. Why isn't the current directory searched? Why isn't foo/bar searched for on PATH? Why is it possible for the user to accidentally remove system commands from PATH and lose access to them? Any system is confusing and surprising to users only familiar

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-18 Thread Paul Moore
Paul Moore added the comment: Well, I'm not convinced that using `shutil.which` is the right answer for anything other than "python". And even there, I'd recommend using `sys.executable` over `shutil.which` in pretty much every case. My view is that if we ignore the "weirdn

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-18 Thread Paul Moore
Paul Moore added the comment: I don't think we should document this level of detail, both because it's basically Windows standard behaviour and therefore not up to us to document, and because it's *way* too overwhelming for the average user

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-18 Thread Paul Moore
Paul Moore added the comment: OK, PR updated as per discussion. -- ___ Python tracker <https://bugs.python.org/issue42041> ___ ___ Python-bugs-list mailin

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-16 Thread Paul Moore
Paul Moore added the comment: > We'd need Mark to weigh in (or possibly track down and ask a colleague), but > I expect the assumption is that subprocess.Popen("python") searches PATH > first. I'm sure it was, TBH. The executable directory side of things is really jus

[issue42055] Python Nuget Packages for Windows Installation: Request for more versions

2020-10-16 Thread Paul Moore
Paul Moore added the comment: Python 3.6.9 and later were source-only security fix releases. We don't provide *any* binary releases for those versions, the nuget distribution is no different in that respect. The release schedule for Python 3.6 is at https://www.python.org/dev/peps/pep-0494

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-16 Thread Paul Moore
Paul Moore added the comment: > This is still true, though, as much as it's ever been. But it's *not*, if I understand the problem here. Windows resolves a bare "python" command by searching the directory containing the running executable first. I would reasonably assume t

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-16 Thread Paul Moore
Paul Moore added the comment: Fair enough. I think we have to be careful here - people do rely on how the "internal" aspects of virtual environments work, like it or not, and we've definitely broken people's code in the past as a result of taking a hardline "it's not docu

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-15 Thread Paul Moore
Paul Moore added the comment: Eryk - I suggest that we modify (or remove) the note in venv that my PR adds as part of such a change, rather than try to qualify the text now (which would probably only make it harder for people to understand the issue

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-15 Thread Paul Moore
Paul Moore added the comment: I've created https://github.com/python/cpython/pull/22715 as a suggested documentation fix. Mark, does this cover what you would have needed to know? Steve, is what I've written technically accurate? -- stage: patch review

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-15 Thread Paul Moore
Change by Paul Moore : -- keywords: +patch pull_requests: +21683 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22715 ___ Python tracker <https://bugs.python.org/issu

[issue42041] venv subprocess call to python resolves to wrong interpreter

2020-10-15 Thread Paul Moore
Paul Moore added the comment: Agreed, this is just "normal Windows behaviour". It's definitely surprising and non-obvious (I saw this issue and it never even occurred to me that this was what was happening) so I'd support documenting it somewhere. My instinct is that the

[issue42013] venv on Windows with symlinks is broken if invoked with -I

2020-10-12 Thread Paul Moore
Paul Moore added the comment: I'm inclined to think that creating a venv from within another venv should be allowed. Tools like pipx can result in *other* tools being run from within a virtual environment, and I don't think it's good to disallow that usage - as an example, I have virtualenv

[issue41774] While removing element from list using for and remove(), which has same items output is not right

2020-09-12 Thread Paul Moore
Paul Moore added the comment: Yeah, apologies - I saw the email notification, but Eric removed me from the nosy list (quite reasonably) and I didn't notice there had been extra discussion :-( If someone wants to re-open the issue, feel free

[issue41774] While removing element from list using for and remove(), which has same items output is not right

2020-09-12 Thread Paul Moore
Paul Moore added the comment: There is a bug in your program. You should not mutate the list while looping over it. -- nosy: +paul.moore ___ Python tracker <https://bugs.python.org/issue41

[issue41774] While removing element from list using for and remove(), which has same items output is not right

2020-09-12 Thread Paul Moore
Change by Paul Moore : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41774> ___ ___

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

2020-09-11 Thread Paul Moore
Paul Moore added the comment: I think this reproduces the underlying issue: >>> import zipfile >>> from pathlib import Path >>> p = zipfile.Path("tst.zip") >>> Path("tst.zip").unlink() Traceback (most recent call last): File "&q

[issue41619] Subprocesses created with DETACHED_PROCESS can pop up a console window

2020-08-23 Thread Paul Moore
Paul Moore added the comment: Confirmed, CREATE_NO_WINDOW works - in my test I used it *with* DETACHED_PROCESS. Is it not a bug that the launcher doesn't respect the value of DETACHED_PROCESS when calling the Python interpreter, though? If nothing else, it means that there are differences

[issue41619] Subprocesses created with DETACHED_PROCESS can pop up a console window

2020-08-23 Thread Paul Moore
Paul Moore added the comment: Originally discovered in https://github.com/pypa/virtualenv/issues/1928 - see that issue for more context. -- ___ Python tracker <https://bugs.python.org/issue41

[issue41619] Subprocesses created with DETACHED_PROCESS can pop up a console window

2020-08-23 Thread Paul Moore
New submission from Paul Moore : The following code pops up an extra console window when run on Windows 10, Python 3.8: from subprocess import DETACHED_PROCESS, Popen p = Popen(["py", "-c", "from time import sleep; sleep(5)"], creationflags=DETACHED_PRO

[issue41565] from os.path import join join('3', '{:3') return '{:3' in windows

2020-08-18 Thread Paul Moore
Paul Moore added the comment: I think the key point here is that os.path.join is *meant* to have platform-native semantics, so it treats '{:' as a drive letter on Windows, but Linux doesn't have drive letters, so os.path.join treats '{:' as a normal part of a filename on Linux

[issue40740] Missing api-ms-win-core-path-l1-1.0.dll for python-3.9.0b1-amd64.exe Under Win7

2020-08-09 Thread Paul Moore
Paul Moore added the comment: https://docs.python.org/3.9/using/windows.html should probably be updated: """ As specified in PEP 11, a Python release only supports a Windows platform while Microsoft considers the platform under extended support. This means that Python 3.9 s

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

2020-07-21 Thread Paul Moore
Paul Moore added the comment: Understood that these would be duplicates, and I certainly don't want to put more pressure on you, but I think there would still be value in having a known reporting channel for people to say "I am also affected by this": * MS Developers get a more

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

2020-07-17 Thread Paul Moore
Paul Moore added the comment: I thought that might be the answer. But does anyone know where I can repost this as an issue against the Store distribution? I'm happy to report there if I can find out how... Hopefully Steve can point me in the right direction

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

2020-07-17 Thread Paul Moore
Paul Moore added the comment: See, for example, https://github.com/pypa/packaging-problems/issues/379 as an illustration of the user (and project maintainer!) confusion this causes. -- ___ Python tracker <https://bugs.python.org/issue41

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

2020-07-17 Thread Paul Moore
New submission from Paul Moore : First of all, I do know that this is an issue with the Windows Store distribution, rather than the python.org one. But (a) I don't know where to report a bug against the Store implementation except here, and (b) it's arguably a case of the Windows

[issue40863] bytes.decode changes/destroys line endings on windows

2020-06-04 Thread Paul Moore
Paul Moore added the comment: Because if you open a file in text mode (without "b" in the mode), Python writes \n (newline) characters as \r\n (carriage return, line feed) which are the Windows textfile representation of "Newline". >From the documentation of the b

[issue40448] ensurepip uses cache directory

2020-05-20 Thread Paul Moore
Paul Moore added the comment: PR looks good to me. There's a test failure that needs fixing and the PR needs a news entry, but otherwise looks fine. -- ___ Python tracker <https://bugs.python.org/issue40

[issue36264] os.path.expanduser should not use HOME on windows

2020-05-16 Thread Paul Moore
Paul Moore added the comment: > Perhaps the best approach for the sake of POSIX compatibility is to set HOME > on startup to the correct value? If Python starts setting `HOME`, that has the potential to affect programs called in a subprocess, possibly breaking them (making them no

[issue40134] Inconsistent ANSI escape code handling on Windows 10

2020-04-01 Thread Paul Moore
Paul Moore added the comment: This works fine for me in Windows terminal, but I see the behaviour described when using the conventional "Command prompt" window. Enabling ANSI codes is handled via SetConsoleMode (see here: https://docs.microsoft.com/en-us/windows/console/setc

[issue39090] Document various options for getting the absolute path from pathlib.Path objects

2020-02-12 Thread Paul Moore
Paul Moore added the comment: You've provided links to your branches, but not to the specific text you're proposing to add. Can you link to a diff or something that shows what you've added more precisely? -- ___ Python tracker <ht

[issue39090] Document various options for getting the absolute path from pathlib.Path objects

2020-02-10 Thread Paul Moore
Paul Moore added the comment: > In short -- I understand that this is a complex issue, but making an absolute > path is a pretty common use case, and we've had os.path.abspath() for > decades, so there should be one obvious way to do it, and it should be easily > disco

[issue39255] Windows and Unix run-time differences

2020-01-08 Thread Paul Moore
Paul Moore added the comment: For me, I headed straight for "Sharing state between processes" and the "Shared memory" object. That's probably because I was reviewing someone else's code, rather than writing my own, but nevertheless when coding I do tend to dive stra

[issue39255] Windows and Unix run-time differences

2020-01-08 Thread Paul Moore
Paul Moore added the comment: Agreed it's not a bug, but I will say it took me a while to work out *why* it's not a bug (namely, that even though the OP is using shared memory values, the code relies on fork semantics to share the two Value objects that *reference* the shared memory

[issue39051] Python not working on Windows 10

2019-12-15 Thread Paul Moore
Paul Moore added the comment: Can you also confirm that the installation of Python was done with the standard Python installer from the python.org website, and is not another distribution (such as Anaconda)? -- ___ Python tracker <ht

[issue39051] Python not working on Windows 10

2019-12-15 Thread Paul Moore
Paul Moore added the comment: > sys.path = [ >'C:\\Developing\\Python\\python38.zip', >'C:\\Developing\\Python\\python-3.8.0.amd64\\Lib\\', >'C:\\Developing\\Python\\python-3.8.0.amd64\\Lib\\lib-tk', >'C:\\Developing\\Python\\python-3.8.0.amd64\\DLLs\\', >

[issue39025] Windows Python Launcher does not update PATH to Scripts directory

2019-12-11 Thread Paul Moore
Paul Moore added the comment: Most items in the Scripts directory can be run using the `-m` flag to Python, so you can use something like `py -m pip` to run pip without needing the Scripts directory in PATH. If an individual project like PyQt doesn't support -m, it's relatively easy

[issue38999] Python launcher on Windows does not detect active venv

2019-12-09 Thread Paul Moore
Paul Moore added the comment: See PEP 486 (https://www.python.org/dev/peps/pep-0486/). This is intended behaviour, as it is assumed that explicitly specifying a Python version means that the user had a specific Python interpreter in mind. There are also technical issues - if the shebang

[issue38999] Python launcher on Windows does not detect active venv

2019-12-09 Thread Paul Moore
Change by Paul Moore : -- Removed message: https://bugs.python.org/msg358060 ___ Python tracker <https://bugs.python.org/issue38999> ___ ___ Python-bugs-list m

[issue38999] Python launcher on Windows does not detect active venv

2019-12-09 Thread Paul Moore
Paul Moore added the comment: See PEP 486 (https://www.youtube.com/watch?v=Lmq13nrEFaM=PLuE3ABw6vYeR0gcPT6uj25ZZhmSP9vRB2=28=0s). This is intended behaviour, as it is assumed that explicitly specifying a Python version means that the user had a specific Python interpreter in mind

[issue38974] using filedialog.askopenfilename() freezes python 3.8

2019-12-04 Thread Paul Moore
Change by Paul Moore : -- nosy: +gpolo, serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue38974> ___ ___ Python-bugs-list mailing list Unsub

[issue38974] using filedialog.askopenfilename() freezes python 3.8

2019-12-04 Thread Paul Moore
Paul Moore added the comment: Can you provide a minimal, self-contained, example of a program that demonstrates this behaviour in 3.8, but works in 3.7. It's not really possible to determine what the issue might be without a means of reproducing the problem. -- components: +Tkinter

[issue38021] pep425 tag for AIX is inadequate

2019-11-26 Thread Paul Moore
Paul Moore added the comment: > replacement platform_tag, not compatibility tag. Ah, I see, sorry. In that case, this should be fine, it's purely a CPython question. There's obviously a follow-on discussion about how that platform tag is *incorporated* into the compatibility t

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

2019-11-25 Thread Paul Moore
Paul Moore added the comment: I presume there's also the option of setting up the environment (or however it's done now - I know the details changed as the feature was developed) so that the "base" python.exe pretends to be the venv one, exactly as the wrapper does. However, tha

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

2019-11-25 Thread Paul Moore
Paul Moore added the comment: Yes, it does. I think we'd need input from Steve Dower here, as these changes were made (I believe) in support of the Windows Store build of Python, so any changes would need to be considered in the light of how they would affect that. I do, however, consider

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

2019-11-25 Thread Paul Moore
Paul Moore added the comment: The behaviour in this area is different between 3.7.0, 3.7.2, and 3.7.3 (at least). I have reproduced the issue with 3.7.3. Steve Dower made changes to the way the python executable works in venvs in the point releases of 3.7 - see https://github.com/pypa

[issue38021] pep425 tag for AIX is inadequate

2019-11-23 Thread Paul Moore
Paul Moore added the comment: Thanks for the clarification, Nick. Yes, I agree that the basic "this is the tag that matches this precise CPython installation" is not the difficult part of the problem here, and if that is all that this issue is targeting, there should be no maj

[issue38021] pep425 tag for AIX is inadequate

2019-11-22 Thread Paul Moore
Paul Moore added the comment: What complicates the issue for AIX (and reminds me very strongly of the MacOS and manylinux situations, both of which were defined after the original tag PEP, and so contain additional insights) is the business of certain tags being compatible across multiple

[issue38021] pep425 tag for AIX is inadequate

2019-11-22 Thread Paul Moore
Paul Moore added the comment: PyPA member here - if this PR is defining new compatibility tags, I would have expected it to need discussion as a revision to PEP 425, much like the manylinux efforts did. (It may actually be a closer parallel with MacOS, which didn't have a tagging PEP - I'm

[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)

2019-10-20 Thread Paul Moore
Paul Moore added the comment: Can you give an example of a script that fails? If you try to print (or otherwise use the standard IO streams) pythonw will fail, because there are no stdio streams for a GUI executable - and the traceback, which goes to stderr by default, will be lost

[issue38369] Python 3.7.4 venv command does not install pip

2019-10-04 Thread Paul Moore
Paul Moore added the comment: Sigh. Never mind, this appears to be because virtualenv uses its own hacked copy of site.py which is missing a lot of the venv support code. I'll report this over on virtualenv. -- resolution: -> third party stage: -> resolved status: open -&g

[issue38369] Python 3.7.4 venv command does not install pip

2019-10-04 Thread Paul Moore
Paul Moore added the comment: Further update - this appears to also happen on Ubuntu (at least the version available through the Windows Linux subsystem), so it's not a Windows-specific issue. -- assignee: steve.dower -> ___ Python trac

  1   2   3   4   5   6   7   >