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.EnvBui
Change by Paul Moore :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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 and
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:
>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
internet
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:
> 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
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 app
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 th
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 ca
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/refe
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
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
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
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
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, con
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.
Ho
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
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: +Tk
Change by Paul Moore :
--
nosy: +gpolo, serhiy.storchaka
___
Python tracker
<https://bugs.python.org/issue38974>
___
___
Python-bugs-list mailing list
Unsub
Paul Moore added the comment:
See PEP 486
(https://www.youtube.com/watch?v=Lmq13nrEFaM&list=PLuE3ABw6vYeR0gcPT6uj25ZZhmSP9vRB2&index=28&t=0s).
This is intended behaviour, as it is assumed that explicitly specifying a
Python version means that the user had a specific Python in
Change by Paul Moore :
--
Removed message: https://bugs.python.org/msg358060
___
Python tracker
<https://bugs.python.org/issue38999>
___
___
Python-bugs-list m
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
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 relativel
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\
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:
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 me
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
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
> discover
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
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/setconsole
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:
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
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
Change by Paul Moore :
--
nosy: +njs
___
Python tracker
<https://bugs.python.org/issue42683>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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 &
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:
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 unreas
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
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
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 flexib
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
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 = GetProcAddress(
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 somewh
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, &dll_path
);
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 a
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 s
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:
Change by Paul Moore :
--
assignee: -> paul.moore
nosy: +Marcus.Smith, dstufft, ncoghlan, pradyunsg
stage: -> patch review
___
Python tracker
<https://bugs.python.org/i
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/4d11ecbb5ed78e6259ee27289c7638
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
Change by Paul Moore :
--
pull_requests: +23203
pull_request: https://github.com/python/cpython/pull/24388
___
Python tracker
<https://bugs.python.org/issue43
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/is
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:
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 updat
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:
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/is
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
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 t
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
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 dire
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
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:
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 par
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:
Originally discovered in https://github.com/pypa/virtualenv/issues/1928 - see
that issue for more context.
--
___
Python tracker
<https://bugs.python.org/issue41
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 differ
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
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:
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
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
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
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
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:
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: pa
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:
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'
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 reasonabl
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
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
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:
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 t
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 &q
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 onl
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:
I like that, I've updated the PR accordingly.
--
___
Python tracker
<https://bugs.python.org/issue42041>
___
___
Python-bugs-l
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/5ab27cc518f614a0b954ff3eb12529
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:
I've raised https://github.com/pypa/pip/issues/9135 for this.
--
___
Python tracker
<https://bugs.python.org/issue42293>
___
___
Paul Moore added the comment:
Any progress on this one?
I tried to reproduce using distutils2, but don't know how distutils2 works -
there's no pysetup and python -m distutils2.run doesn't work the same as python
-m packaging.run.
Can we at least get packaging working in tim
Paul Moore added the comment:
We're running a bit lower on time now. Any progress? The whole discussion on
python-dev around binary formats petered out with no real conclusions :-(
--
___
Python tracker
<http://bugs.python.org/is
Paul Moore added the comment:
Have you had a chance to look at this yet?
--
___
Python tracker
<http://bugs.python.org/issue13123>
___
___
Python-bugs-list mailin
Paul Moore added the comment:
> Maybe you’re using the old PyPI release or Tarek’s outdated Bitbucket
> repository. http://hg.python.org/distutils is current, contains pysetup and
> supports -m distutils2.run.
I just did pip install distutils2 in a virtualenv. If that doesn't
Paul Moore added the comment:
I'm writing a PEP, also as a result of Nick's suggestion on python-ideas. I
don't think it will be too hard to get the basic framework of the PEP in place.
When I'm done, would you like to see it and comment before I post to the wider
pyt
Paul Moore added the comment:
I'll try to take a look over the next couple of days.
--
___
Python tracker
<http://bugs.python.org/issue13123>
___
___
Pytho
Paul Moore added the comment:
>> Do I need to hg clone then do some magic pip incantation to get it installed?
> Why would you want to install it? Clone it, hack on it in place, run tests
> in place. :)
>
> FTR, “bin/pip install -e .” is the command to “install” a project
Paul Moore added the comment:
A better example in terms of "intended to be text" might be ChangeLog files.
These are clearly text files, but of sufficiently standard format that they can
be manipulated programmatically.
Consider a program to get a list of all authors who changed a
Paul Moore added the comment:
Produces RECORD files with CR-CR-LF line endings (see issue13175). This breaks
pysetup remove.
I can't tell if this patch is good otherwise - it's certainly no worse than the
behaviour of the unpatched version, but that's
101 - 200 of 677 matches
Mail list logo
