Paul Moore added the comment:
As noted in the related issue that you link to, there is not meant to be a
deactivate.ps1 script - the deactivate command is provided via a global
deactivate function created when you run activate.ps1 (although this is an
implementation detail, all that matters
Paul Moore added the comment:
Hi Cheryl,
Looks like I dropped the ball on this one :-( I think it just needs to be
applied to the main branch (3.7/3.8) - I don't think it's worth backporting.
I'll try to get to it when I can, but it may not be for a few weeks, as I have
ot
Paul Moore added the comment:
New changeset 4be79f29463f632cd8b48486feadc2ed308fb520 by Paul Moore (Cheryl
Sabella) in branch 'master':
bpo-28247: Document Windows executable creation in zipapp (GH-6158)
https://github.com/python/cpython/commit/4be79f29463f632cd8b48486feadc2
Paul Moore added the comment:
Pip 10 has now been released. I'll be getting a PR to put it into 3.7 in the
next few days. One question on workflow - is the right approach to create a PR
for master and request a backport to the 3.7 branch? Or is there something else
I should do?
Also,
Paul Moore added the comment:
Thanks Nick, that's what I thought for the workflow. And agreed with your
understanding of the post-b4 question, but as you say Ned's the boss on that
one :-)
--
___
Python tracker
<https://bugs.python.o
Paul Moore added the comment:
Issues with pip should be reported at https://github.com/pypa/pip/issues rather
than here. However, in this case, the issue is that you ran the command "pip
install --upgrade pip" which will use the pip executable to upgrade itself,
something that Wind
Change by Paul Moore :
--
keywords: +patch
pull_requests: +6243
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue33131>
___
_
Paul Moore added the comment:
New changeset 0399cf9b5e370516e3d0aed6a63ff74aff5eadb5 by Paul Moore in branch
'master':
bpo-33131: Upgrade ensurepip to bundle pip 10.0.1 (GH-6546)
https://github.com/python/cpython/commit/0399cf9b5e370516e3d0aed6a63ff7
Paul Moore added the comment:
As I noted on python-ideas, continuing to search along sys.path if the loader
returns None seems to match what the linecache docs say. If the issue had been
phrased as "the implementation of linecache doesn't follow the docs" then I'd
Paul Moore added the comment:
>> IMO, debating whether a None return means there's absolutely no chance of
>> there being source is silly - the best the loader can say is that it can't
>> provide source.
>
> I don't think it is silly: if "None"
Paul Moore added the comment:
> How does CPython display the source for tracebacks in Cython modules? It
> seems to work there as long as the Cython .pyx files are somewhere in the
> import path.
Is that in Python 3.x? The issue we're discussing is only
Paul Moore added the comment:
That's interesting. It sounds like linecache might be working differently then.
--
___
Python tracker
<https://bugs.python.org/is
Paul Moore added the comment:
Supplying cum_weights allows the code to use bisection to locate the correct
value to return. This is O(log n), and is significantly faster for large
populations than supplying weights (which need to be totalled for the
calculation).
Requiring a pre-check on
Paul Moore added the comment:
I would strongly prefer the docs to be changed to match the implementation
rather than the other way round. However, I don't see the use case for this -
what case sensitive filesystem would anybody be building the Windows version of
Python on?
I&#x
Paul Moore added the comment:
OK, having re-read the PR, I'm fine with applying it as is, too.
--
___
Python tracker
<https://bugs.python.org/issue31569>
___
___
Paul Moore added the comment:
New changeset f1502d097c29b266a5748312ee2451a2d6ac0af6 by Paul Moore (Stefan
Grönke) in branch 'master':
bpo-31569: correct PCBuild/ case to PCbuild/ in build scripts and docs (GH-3711)
https://github.com/python/cpyt
Paul Moore added the comment:
I believe that's the case, although I'm somewhat surprised by the nature of the
error. I'm just checking diffs at the moment.
But VS 2015 is the officially supported compiler for 3.6.
--
___
Python
Paul Moore added the comment:
Standard Windows behaviour, in my experience, is inherited permissions.
IMO, the current behaviour is correct - we default to an OS-managed secure
location for system wide installs, and a user-modifiable location for user
installs. If the person doing the
Paul Moore added the comment:
Definitely. The reason it uses uncompressed files is simply an oversight on my
part - I hadn't realised the default for zipfile was uncompressed.
--
___
Python tracker
<https://bugs.python.org/is
Paul Moore added the comment:
New changeset d87b105ca794addf92addb28293c92a7ef4141e1 by Paul Moore (Zhiming
Wang) in branch 'master':
bpo-31638: Add compression support to zipapp (GH-3819)
https://github.com/python/cpython/commit/d87b105ca794addf92addb28293c92
Change by Paul Moore :
--
assignee: -> paul.moore
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python
Paul Moore added the comment:
The "backports" module you refer to as being in site-packages is not shipped
with the standard library, it's a 3rd party addon that presumably you installed
yourself. You'll need to let us know what you did to install it.
You say you manipula
Paul Moore added the comment:
> I did use `pip` to install packages as you'll see in the screenshot.
Sorry, I don't see any pip commands. Please could you include sample commands
inline as text, and not as screenshots, as attached files aren't accessible
from emails...
A
Paul Moore added the comment:
My feeling is still that it's an issue with things (i.e., imports) happening
before you adjust sys.path. But without seeing actual code that reproduces the
issue, there's no way of being sure. And if that is what's going on, it
wouldn't b
Paul Moore added the comment:
Also, one of the packages installed creates a file
configparser-3.5.0-py2.7-nspkg.pth
This has some very suspicious looking content:
import sys, types, os;has_mfs = sys.version_info > (3, 5);p =
os.path.join(sys._getframe(1).f_locals['sitedir'],
Paul Moore added the comment:
I'm not actually sure what the proposal here is. Are we suggesting that all
Python's means of terminating a process should use the same exit code?
Note that doing so would be a backward compatibility break, as os.kill() is
documented as having the beha
Paul Moore added the comment:
The docs for the curses module say "While curses is most widely used in the
Unix environment, versions are available for Windows, DOS, and possibly other
systems as well." This is the only mention of platform support I can see.
It might be worth
Paul Moore added the comment:
@elguavas the problem is, no-one has proposed a patch. There's not likely to be
much movement on this until someone provides one.
--
___
Python tracker
<https://bugs.python.org/is
Paul Moore added the comment:
Personally I don't see the value (in general, I don't see much use for the
whole custom command idea - making the launcher into a generalised shebang
processor was never really a core feature). But I'm not going to say no if
others find it useful
Paul Moore added the comment:
Good catch, thanks Serhiy!
--
___
Python tracker
<https://bugs.python.org/issue31998>
___
___
Python-bugs-list mailing list
Unsub
Paul Moore added the comment:
This is a pip issue, not a Python issue. It's a known issue in the current
version of pip, and should be fixed in the development version (via pull
request https://github.com/pypa/pip/pull/4486).
If you like, you can try the development version of pip. A
Paul Moore added the comment:
Does this mean that we'll need to update the bundled ucrt whenever there are
security patches to the baseline version? Are we happy with the security
implications of that?
I thought one of the key advantages of using the system CRT (whether the old
msvcrX
Paul Moore added the comment:
Oh, so we're talking here about bundling the ucrt installers and then if the
user doesn't already have ucrt installed system wide, we will install a local
copy, but if they do, we don't do anything? If we install a local copy, then
it'll be
Paul Moore added the comment:
You could add the line
import sys; sys.path.insert(0, '')
to a .pth file. The documentation you pointed out states that lines starting
with "import" are executed...
--
___
Py
Paul Moore added the comment:
See https://docs.python.org/3.7/tutorial/floatingpoint.html. Essentially, the
behaviour you are seeing is caused by the fact that the results calculations
you are attempting cannot be exactly represented in binary floating point, so
approximate results are
Paul Moore added the comment:
> What's wrong with that? Installing the .pyx sources together with the .so
> compiled modules makes a lot of sense to me: it is very analogous to
> installing the .py sources together with the .pyc byte-compiled files. In
> https://bugs.pyth
Paul Moore added the comment:
On Sun, 5 Aug 2018 at 06:51, Stefan Behnel wrote:
> This whole idea looks backwards and complicated. As Brett noted, .pyc files
> were moved out of the source tree, because they are build time artifacts and
> not sources. With that analogy, it's
Paul Moore added the comment:
So, where is the filename coming from? Looking at exception and frame objects,
I don't see a "source filename" attribute anywhere - have I missed something
here?
--
___
Python tracker
<https
Paul Moore added the comment:
On Sun, 5 Aug 2018 at 18:10, Brett Cannon wrote:
> One other thing I will say is that the PEP 302 APIs were seemingly designed
> for working with Python source and were not necessarily oriented towards
> alternative code representations that were exec
Paul Moore added the comment:
If you're OK with that, I don't see the problem. My objection was with the
claims that ExtensionLoader.get_source shouldn't return None or shouldn't
exist. PEP 302 mandates that loaders have a get_source, and that get_source
should retur
Paul Moore added the comment:
>From https://docs.python.org/3.7/using/windows.html#shebang-lines the
>supported shebang lines are
* /usr/bin/env python
* /usr/bin/python
* /usr/local/bin/python
* python
There's a provision in there:
"""
The /usr/bin/env form of sh
Change by Paul Moore :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34359>
___
___
Paul Moore added the comment:
Others use absolute paths, as I mentioned in my reply.
--
___
Python tracker
<https://bugs.python.org/issue34359>
___
___
Pytho
Paul Moore added the comment:
Oh, and I suspect that the reason that "The thing with the relative path works
if I change the order in the path" is simply because the bit of code that
searches PATH just ignores what's after #!/usr/bin/env and looks for
python.exe. (More or l
Paul Moore added the comment:
I don't see an appveyor.yml file in the CPython repository. How are
the appveyor builds configured? I was going to take a look, but need
to see the config :-(
On Wed, 5 Sep 2018 at 10:32, STINNER Victor wrote:
>
>
> STINNER Victor added the comment
Paul Moore added the comment:
One thought - appveyor.yml says that the cache of externals depends on PCBuild.
Could it be that appveyor is caching PCBuild to verify whether it's changed
(and hence whether to use the cached externals)? I know that sounds bizarre,
but I'm not ent
Change by Paul Moore :
--
nosy: -paul.moore
___
Python tracker
<https://bugs.python.org/issue34694>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
I don't think this is expected behaviour. It's not documented what should
happen in this case but the behaviour suggested by the OP (to search for the
path as given, followed by [path+e for e in
os.environ['PATHEXT'].split(os.pathsep)] se
Paul Moore added the comment:
On further reflection, I'm less sure that the proposed behaviour is the best
option, but I do think this warrants further consideration.
--
___
Python tracker
<https://bugs.python.org/is
Paul Moore added the comment:
There's also https://pypi.python.org/pypi/sarge
One other thing I *often* want to do when scripting commands is to capture
output, but provide some form of "progress" reporting (something like a dot per
line of output, usually). That's ann
New submission from Paul Moore:
Some small improvements to the powershell "Activate" script for venvs:
1. Can be run as a command, rather than needing to be dot sourced. This matches
the behaviour of bat files, and of virtualenv's "activate" script, and avoids a
New submission from Paul Moore:
Adds "exe wrapper" functionality to the Windows launcher. This is a preliminary
patch, for comments - the code is there and works, but I need to add
documentation (and maybe tests - are there any existing tests for the launcher?)
Also to be consider
Changes by Paul Moore :
--
keywords: +patch
Added file: http://bugs.python.org/file30966/launcher_wrapper.patch
___
Python tracker
<http://bugs.python.org/issue18
Changes by Paul Moore :
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue18491>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Correct about .pyw files - I had forgotten those, I will update the patch.
The idea of "support code" was to (somewhat) alleviate Mark's question about
"what is this for", I was wondering if it was worth adding a module to the
stdlib whic
Paul Moore added the comment:
I've no problem with that suggestion. The patch is clean enough that ifdef-ing
it out won't be hard.
Revised patch incoming :-) It's needed for the pyw support in any case.
--
___
Python
Paul Moore added the comment:
Updated patch, as per discussion.
--
Added file: http://bugs.python.org/file30994/launcher_wrapper.patch
___
Python tracker
<http://bugs.python.org/issue18
Changes by Paul Moore :
Removed file: http://bugs.python.org/file30966/launcher_wrapper.patch
___
Python tracker
<http://bugs.python.org/issue18491>
___
___
Python-bug
New submission from Paul Moore:
Make the Windows Python installer set PATHEXT when "Register Python extensions"
is set. This allows users to run a scripy by typing the name of the .py file at
the command line without the .py extension.
The patch needs review - I have not been abl
Paul Moore added the comment:
Applies and builds cleanly on Win7 32-bit. The speed difference is visible here
too:
PS D:\Data\cpython\PCbuild> .\python.exe -m timeit -s "from _thread import
allocate_lock; l=allocate_lock()" "l.acquire();l.release()"
100 loops, be
Paul Moore added the comment:
The applied fix appears to have a regression - the file argument is not allowed
to be None. The pywin32 post-install script calls imp.load_module for a C
extension with file=None, so presumably this worked in earlier versions.
The regression breaks the
Paul Moore added the comment:
On 10 September 2012 11:47, Tim Golden wrote:
>
> Tim Golden added the comment:
>
> Paul, are you using the hg tip of pywin32? pywin32_postintall.py was
> patched a couple of months ago to use imp.load_dynamic (essentially to
> work around this is
New submission from Paul Moore:
imp.load_module appears to have a regression - the file argument is not allowed
to be None when loading a C_EXTENSION. The pywin32 post-install script for
version 217 calls imp.load_module for a C extension with file=None, so
presumably this worked in earlier
Paul Moore added the comment:
Logged as #15902.
--
___
Python tracker
<http://bugs.python.org/issue15828>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
It's the open file object argument, not the path. I assume that if you
supplied None, the code opened the file for you.
--
status: pending -> open
___
Python tracker
<http://bugs.python.org
Changes by Paul Moore :
--
nosy: -pmoore
___
Python tracker
<http://bugs.python.org/issue13198>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
I've been around here for a while, but yeah, I'll keep an eye out for pip stuff
now, too. Good thought.
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
Checking the exact error could be a bit fragile. I have a feeling I recently
saw an issue somewhere with code that stopped working on Python 3.4 because the
precise error raised for a read-only file changed. I don't recall where the
issue was, unfortun
Paul Moore added the comment:
TBH, I don't think I ever took this any further. As noted, the earlier patches
fixed the failures I was hitting.
It looks like Python 3.4 now has *two* definitions of find_unused_port, in
test.test_support and in test.support. And test_asyncio and test_f
Changes by Paul Moore :
--
nosy: -pmoore
___
Python tracker
<http://bugs.python.org/issue8576>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Moore:
The documentation for venv states that __VENV_NAME__ in scripts is replaced by
the name of the virtualenv. In fact, it is replaced by context.prompt, which is
the prompt, rather than the name.
The various activate scripts are not consistent with this behaviour
Paul Moore added the comment:
Cool. Patch attached (this fixes __VENV_NAME__ and implements __VENV_PROMPT__)
--
keywords: +patch
Added file: http://bugs.python.org/file31938/venv_prompt.patch
___
Python tracker
<http://bugs.python.org/issue19
Paul Moore added the comment:
How about simply adding a further sentence, something like:
"Where a class is being used conceptually as a callable (for example, context
managers), the naming convention for callables (lower_case_with_underscores)
should be followed."
Maybe also add
Paul Moore added the comment:
+1 on switching the wording in the overriding principle section to say "factory
function to class". Although the fact that I made that mistake reflects my
point that if I'm thinking of class->wrapper as an "internal change" then I'
Paul Moore added the comment:
I'm in favour of keeping it simple - "use your common sense" should be a
general guideline here (even though I know people's tastes differ, and that can
be a source of endless debate :-))
--
___
P
Changes by Paul Moore :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9055>
___
___
Python-bugs-list
New submission from Paul Moore:
It would be useful for shutil.rmtree to have a "force" argument that overrode
read-only permission issues, essentially replicating the behaviour of the -f
flag in rm -rf (Unix) and the -force parameter of del (Windows Powershell).
It's poss
Paul Moore added the comment:
Doh. And I was even involved in the previous issue. Sorry for the noise.
--
___
Python tracker
<http://bugs.python.org/issue22
Paul Moore added the comment:
I'm not sure how relevant this is any more, as pip is the preferred installer
these days and it cleanly uninstalls projects. At least for my usage, I no
longer use wininst installers at all. I won't close this myself, though, as the
issue still exi
Paul Moore added the comment:
It's not unreasonable as a new feature, but the default behaviour shouldn't
change. It matches ini files (like it or not, ConfigParser parses ini-style
files - the docs even say so), and sectionless values are not standard ini
format.
I'd suggest
Paul Moore added the comment:
>From the comments here, there seems to be a belief that this is somehow
>related to VC Express only.
I have hit this error when using the MS SDK (both 7.0 on Python 2.7, and 7.1 on
Python 3.3 and 3.4) with DISTUTILS_USE_SDK set.
Unless I have s
New submission from Paul Moore:
The Python 3.4b2 installer for Windows does not install a "pip.exe" wrapper
when the default options are selected. Only the "pip3.exe" and "pip3.4.exe"
commands are provided.
The documentation for ensurepip makes it clear that
Paul Moore added the comment:
Fair enough. Can the justification be recorded somewhere, please? It's
inconsistent with most other Python commands on Windows. (I don't recall what
the justification was, and can't come up with a search that locates the
di
Paul Moore added the comment:
It would not be impossible for the ensurepip call in the Windows installer to
set the --default-pip flag, if that gives a better user experience on Windows.
I'm not wedded to either answer myself, but given that versioned executable
names are uncommon on Wi
Paul Moore added the comment:
The most obvious solution would be if the onerror argument allowed for retries.
At the moment, all it can do is report issues, not recover. Suppose that
returning True from onerror meant "retry the operation". Then you could do
def set_rw(operation,
Paul Moore added the comment:
It's similar. But the problem is that it only returns a list of errors, it
doesn't let you address the error *while the rmtree is in progress*.
The key thing is that if you can fix the problem in onerror, you can avoid
needing to restart the whole
Paul Moore added the comment:
Looks like that works. At least in my case - I just did
def del_rw(action, name, exc):
os.chmod(name, stat.S_IWRITE)
os.remove(name)
shutil.rmtree(path, onerror=del_rw)
Something more robust might check if name is a directory and os.rmdir
Paul Moore added the comment:
Is there any chance this can be included in Python 3.4? It would apparently
allow numpy to be built with stock tools on Windows Python.
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue16
Paul Moore added the comment:
Unfortunately not really - it's the numpy guys that need this, so hopefully the
original poster can comment.
I'll see if I can hand-patch the relevant files and do a pip install numpy to
see if it fixes that specific scenario. I'll report back.
I
Paul Moore added the comment:
Sigh. Looks like it doesn't fix the issue of building numpy - plus it doesn't
apply cleanly. My apologies for the noise, I'll report the issues with the
patch back on the numpy issue where I was told a
Paul Moore added the comment:
Maybe it's not applicable to 3.3 somehow, which is what I tried. I applied the
patch to the distutils in the system installed Python, then ran pip install
numpy from a virtualenv.
It's quite possible that a million things could have gone wrong in th
Paul Moore added the comment:
Nothing obvious or Windows-specific from what I can see. It does seem to me
that EnvironmentVarGuard doesn't monkeypatch os.environ even though it looks
like it intends to (__exit__ sets it back, but __enter__ doesn't monkeypatch
it). So maybe th
Paul Moore added the comment:
Sigh. Yes, I looked at that and wondered if os.devnul would show as existing,
but I similarly misread the test and assumed it was testing what it was meant
to test :-(
os.path.exists(os.devnull) is false on Windows (just checked) so this
assumption *is* what&#
Paul Moore added the comment:
In ensurepip, _disable_pip_configuration_settings has the line:
os.environ['PIP_CONFIG_FILE'] = os.devnull
On Windows, os.devnull does not behave like a real file in that
os.path.exists(os.devnull) is False even though opening it works fine. So tha
Paul Moore added the comment:
Maybe. I don't know what *else* might fail because devnull is special. The
filename gets passed straight to configparser, for a start.
But if you want to do that I'm OK with that - I just won't make that change
myself. Would the special-casing
Paul Moore added the comment:
As noted in http://bugs.python.org/issue1311 (referenced from
http://bugs.python.org/issue20541) it's not actually correct to assume that
os.path.exists(os.devnull) returns true, as on Windows the "null device" is not
a proper filesystem object.
Paul Moore added the comment:
Sounds reasonable. Having thought about it a bit more, I don't think it's a big
deal. I'll put a PR together for special-casing devnull.
--
___
Python tracker
<http://bugs.pyt
Paul Moore added the comment:
https://github.com/pypa/pip/pull/1543
--
___
Python tracker
<http://bugs.python.org/issue20053>
___
___
Python-bugs-list mailin
Paul Moore added the comment:
Fix now merged into pip 1.5.X branch
--
___
Python tracker
<http://bugs.python.org/issue20053>
___
___
Python-bugs-list mailin
Paul Moore added the comment:
I had not noticed that, but yes. It would be unreasonable on Windows to install
pip3 and pip3.4 but not plain pip. So +1 on this change.
(In fact, on Windows, omitting the versioned names would conform more closely
to how Python is installed, but it'
301 - 400 of 677 matches
Mail list logo
