Paul Moore added the comment:
This is Windows (shell) behaviour. To avoid this, you need to add the .py
extension to the PATHEXT environment variable.
--
___
Python tracker
<https://bugs.python.org/issue47
Paul Moore added the comment:
> as well as potentially being able to be a script or .pyz launcher with a
> simple rename.
Would it be possible to also make the launcher work when prepended to a
zipfile? That's a really useful use-case (make a zipapp automatically runnable,
but
Paul Moore added the comment:
I tend to agree with Steven and David here. You define __getattribute__ and so
that's the behaviour you get when an attribute of the class is requested
(whether by the system or by your code). The documentation (here:
https://docs.python.org/3/reference
Paul Moore added the comment:
Well, we don't support doing that - so I'm not sure what you want beyond the
statement "it's not supported". If it works for you, then by all means use it,
but you'll be on your own for any issues you encounter unless you can reproduce
them in
Paul Moore added the comment:
That's probably because you're using Python 3.10 (assuming the "version" tag
you added is correct) and those libraries haven't released Windows binaries for
Python 3.10 yet.
You should wait for binaries to be released, and check with the projects
Paul Moore added the comment:
> I don't know technical details but i can successfully use this command: `pip
> install --upgrade pip`.
On Windows (and not under something like cygwin or msys, which have their own
rules)? Anyway, it's not that important, the recommended approach is `
Paul Moore added the comment:
> You are wrong. Windows lets me update pip via pip.
You have misinterpreted what you are seeing.
> Should i create new issue for this?
No, you should follow the correct process and use `python -m pip`, and not use
pip di
Change by Paul Moore :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45148>
___
___
Paul Moore added the comment:
>From the documentation:
> upgrade indicates whether or not to upgrade an existing installation of an
> earlier version of pip to the bundled version.
Note the comment "to the bundled version". This command will not access the
i
Paul Moore added the comment:
It works as expected (the print statement in the "finally" clause is executed)
for me.
--
___
Python tracker
<https://bugs.python.o
Paul Moore added the comment:
See the attached screenshot. Only the app name is visible by default.
I see no benefit to the change and a definite usability degradation for people
like me with multiple Python versions.
--
Added file: https://bugs.python.org/file50152/Apps
Paul Moore added the comment:
In "Apps and Features" on Windows 10, the application name is shown by default
but not the version. I have 3 different versions of Python installed on my PC
and if they all reported as "Python" it would be a lot harder to manage them
(I'd h
Paul Moore added the comment:
It does for me:
>>> help(open("nul").writelines)
Help on built-in function writelines:
writelines(lines, /) method of _io.TextIOWrapper instance
Write a list of lines to stream.
Line separators are not added, so it is usual for ea
Change by Paul Moore :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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&
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
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
Paul Moore added the comment:
It can be closed.
--
___
Python tracker
<https://bugs.python.org/issue41490>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Change by Paul Moore :
--
pull_requests: +23203
pull_request: https://github.com/python/cpython/pull/24388
___
Python tracker
<https://bugs.python.org/issue43
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
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
Change by Paul Moore :
--
assignee: -> paul.moore
nosy: +Marcus.Smith, dstufft, ncoghlan, pradyunsg
stage: -> patch review
___
Python tracker
<https://bugs.python.org/i
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
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
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
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 (
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
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
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
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
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
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
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
Paul Moore added the comment:
"http:" isn't a valid drive letter, I'd imagine.
--
___
Python tracker
<https://bugs.python.org/issue42855>
___
___
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 "
Change by Paul Moore :
--
nosy: +njs
___
Python tracker
<https://bugs.python.org/issue42683>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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
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
Paul Moore added the comment:
I've raised https://github.com/pypa/pip/issues/9135 for this.
--
___
Python tracker
<https://bugs.python.org/issue42293>
___
___
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
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
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
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
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
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
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
Paul Moore added the comment:
OK, PR updated as per discussion.
--
___
Python tracker
<https://bugs.python.org/issue42041>
___
___
Python-bugs-list mailin
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
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
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
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
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
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
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
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
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
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
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
Change by Paul Moore :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41774>
___
___
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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\\',
>
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
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
1 - 100 of 675 matches
Mail list logo
