New submission from Paul Moore:
Console code page issues are a consistent source of problems on Windows. It
would be nice, given that the Windows console has Unicode support, if Python
could write the full range of Unicode to the console by default.
The MSVC runtime appears to have a flag
Paul Moore added the comment:
Presumably this would just be a case of moving "activate" from
venv/scripts/posix to venv/scripts/common? I don't think including csh or fish
scripts on Windows is worthwhile...
Attached is a patch on that basis. I didn't see any tests for
Paul Moore added the comment:
On Windows, subprocess.Popen has to convert an argument list to a command line
(because that's what the OS expects for CreateProcess). It does so internally,
using subprocess.list2cmdline, which follows the quoting rules for the MS C
runtime (because that&#
Paul Moore added the comment:
A few minor review comments. Nothing substantial, tbh. Looks good.
--
___
Python tracker
<http://bugs.python.org/issue23731>
___
___
Paul Moore added the comment:
Assuming new code should be using pathlib, I agree this should probably be
closed now as obsolete.
One proviso - pathlib objects don't take a bytestring path in the constructor.
If there's a need for a low-level splitpath taking bytes objects, there may
Paul Moore added the comment:
The patch looks good to me.
rhettinger: I'm not sure I see a problem with the doc changes in the latest
patch - noting that commonprefix may return an invalid path is fine, and what
the current docs say. Directing people to commonpath if they don't wa
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue14243>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
It returns True.
--
___
Python tracker
<http://bugs.python.org/issue23808>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
I believe it's the way it is because Python follows the Standard Decimal
Specification, which includes tests for conformance to the current formatting
behaviour.
--
nosy: +paul.moore
___
Python tracker
Paul Moore added the comment:
The correct solution to this issue now is to install the Microsoft supplied
"Visual C++ Compiler for Python 2.7" package (available as a free download from
MSDN). That has all the components needed to build 32 and 64-bit extensions.
Your setup.py ne
Paul Moore added the comment:
I think the main (only?) user of having sys.path entries in the registry is
pywin32. It might be worth asking them if they can switch to a more mainstream
approach, and then maybe the whole registry finder thing can be removed
completely.
--
nosy
Paul Moore added the comment:
There's actually a bug in the pre-3.5 script beyond the "does the directory
exist" check. The code is
if hasattr(site, "USER_SITE"):
userpath = site.USER_SITE.replace(appdata, "%APPDATA%")
userscripts = os.pa
Paul Moore added the comment:
One further thought. This is a change in behaviour (albeit to a script in
Tools), so I'm inclined to say it's a new feature for 3.5, rather than a bugfix
to be backported to 2.7 and 3.4.
For users of 2.7/3.4, the workaround is simply to rerun the s
Paul Moore added the comment:
Cool. I'll try to set up a test (it's not covered by the testsuite AFAICT) on a
VM or something, just to confirm I haven't broken anything.
--
___
Python tracker
<http://bugs.pyt
Paul Moore added the comment:
Here is a patch to fix the issue.
--
keywords: +patch
Added file: http://bugs.python.org/file38659/addpath.patch
___
Python tracker
<http://bugs.python.org/issue16
Paul Moore added the comment:
One further thought - the installer can't create the user scripts directory if
you're doing an all-users install, that's sort of the point of "all users". It
could do so for a per-user install, but then there would be an inconsistency
tha
Paul Moore added the comment:
I think the problem here is that as the OP mentioned, win_add2path.py doesn't
add the directory if it doesn't exist, so if you run it immediately after
install, it won't add the directories that don't exist yet. And because it's
settin
Paul Moore added the comment:
... because I think it does do that (see
http://bugs.python.org/file38085/userscripts.patch which updates this file)
--
___
Python tracker
<http://bugs.python.org/issue16
Paul Moore added the comment:
Steve - is it the fact that it's not using the versioned user-site directory
that you're referring to?
--
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
Pip and/or setuptools will add the Scripts directory when needed, so it's not a
big deal that the installer doesn't create it. In 2.7.9 and later, and 3.4
onwards, the Scripts directory is created as part of the ensurepip step of the
install, so it
Changes by Paul Moore :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Paul Moore added the comment:
That sounds reasonable. I understand the need for face-to-face discussion on
something like this, although I do think there's been something of a tendency
in the past for things "decided at PyCon" to receive a certain amount of
resistance from peo
Paul Moore added the comment:
I agree with Ned, this sounds like a significant change. In particular,
Portable Python seems to currently only offer 3.2.5 at the moment. And it's not
at all clear to me whether it's a 32-bit or a 64-bit version (but I suspect the
former). One thing I
Paul Moore added the comment:
Sorry, SOE?
--
___
Python tracker
<http://bugs.python.org/issue22516>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Regarding the "poor relation" argument, I'd see that as the other way round. We
don't have the resources to deal with major breakages, so we should be
relatively cautious.
--
___
Python tracker
<
Paul Moore added the comment:
Personally, I'd like to have 3.5 be the release that changes to using "Program
Files" as the default install, and offers a per-user install to Appdata. I
suspect there will be enough fallout from that change to keep us busy. Let's
look to 3.6
Paul Moore added the comment:
Updated patch with fixes for review comments. I did remove the tests for the
exact error messages, as testing for a non-zero exit code was actually what I
was trying to do, and I found a better way of doing that.
--
Added file: http://bugs.python.org
Paul Moore added the comment:
One implication of Nick's (and Steve's) position seems to me that we don't view
per-user installs as a key aspect of the python.org installers. And yet the
impression I get of the direction that the 3.5 installers is taking seems to
contradict t
Paul Moore added the comment:
> 99% of Python users should be getting a distribution rather than the
> python.org installers
I'm not at all convinced by this logic. On Windows, as far as I'm aware, the
only "major" Python distributions are Anaconda and Enthought, b
Paul Moore added the comment:
Updated patch. Added the requested test and a set of tests for the command line
API. This also highlighted a bug in the command line --info option, which is
also fixed.
Coverage now:
Name Stmts Miss Cover Missing
Paul Moore added the comment:
Cool, no problem.
--
___
Python tracker
<http://bugs.python.org/issue23700>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Agreed, the test is sufficient documentation. However, I can't make the test
fail here (Windows 7, Python 3.4.3):
>py ti.py
b'spam\n' b'spam\n'
b'eggs\n' b'eggs\n'
b'beans\n' b'beans\n'
>ca
Paul Moore added the comment:
LGTM, just one minor comment in review.
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue23681>
___
___
Pytho
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue23701>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Egg files are a format defined by setuptools. If you look in the setuptools
documentation it notes that egg files are simply zipfiles with a particular
structure and naming convention. So from a core Python perspective, you can use
eggs just like any other
Paul Moore added the comment:
Updated version of the patch with tests, plus doc update noting that path
objects are explicitly supported.
--
Added file: http://bugs.python.org/file38513/duck_typed_zipapp.patch
___
Python tracker
<h
Paul Moore added the comment:
Cool, I'll look at sorting it out.
--
___
Python tracker
<http://bugs.python.org/issue23657>
___
___
Python-bugs-list m
Paul Moore added the comment:
Looks good. Would it be worth adding tests for providing pathlib.Path objects,
or is that overkill?
--
___
Python tracker
<http://bugs.python.org/issue23
Paul Moore added the comment:
Thanks Brett! Apologies about the TESTFN issue - I changed it (from
TemporaryDirectory, in fact) based on one of the review comments - it looks
like I didn't test the change properly. My mistake, thanks for catchi
Paul Moore added the comment:
That sounds reasonable. I'll have a look at this. The code was originally based
on a similar pattern in the zipfile module, so maybe zipfile should be changed
in the same way?
--
___
Python tracker
Paul Moore added the comment:
The patch would need updating to be applicable. Minimum changes I would expect
to be required:
1. Update to build for Python 3.5 (the patch will *not* be included in earlier
versions, as it is a new feature), which means it needs the Visual Studio 2015
build
Paul Moore added the comment:
Steve has something like that planned, I believe. It's been discussed a couple
of times on python-dev
--
___
Python tracker
<http://bugs.python.org/is
New submission from Paul Moore:
Installing Python 3.5a2 with the 64-bit Windows installer using a user-level
install doesn't associate .py files with the new (3.5) version of the launcher.
I encountered this when there was an existing system install of Python 3.4, so
.py files rem
Paul Moore added the comment:
OK, so if the installer changes look good to you, then this PR is once again
ready to go. Sorry to anyone watching for the glitch.
--
___
Python tracker
<http://bugs.python.org/issue23
Paul Moore added the comment:
Steve Dower - could you please review the updated patch here. The WiX changes
specifically are intended to register the .pyz extension with the launcher, but
I can see no code that does this for a per-user install. I've copied the same
code for the .py exte
Paul Moore added the comment:
There's a problem with the latest patch, it's lost the MSI updates somehow.
I'll add them back in this evening, please don't commit before a v6 patch is
available,
--
___
Python tracker
<
Paul Moore added the comment:
Please don't install the installer somewhere, just to add an uninstall icon on
the start menu. It's possible to uninstall via "Add/Remove Programs". That
should be sufficient.
--
___
P
Paul Moore added the comment:
At a minimum, the example should show adding setting the 2 script directories
to PATH, and not just sys.prefix.
--
___
Python tracker
<http://bugs.python.org/issue23
New submission from Paul Moore:
With Python 3.5 on Windows defaulting (for all users installs) to the read-only
"Program Files" directory, and with "Add Python to PATH" having problems adding
the per-user "user scripts" directory to PATH, the Python 3.5 docum
Paul Moore added the comment:
Sent via private email as it's a work PC and I didn't check what's logged in
there...
--
___
Python tracker
<http://bugs.pyt
New submission from Paul Moore:
When I installed Python 3.4, I included the py.exe launcher. I have just
installed Python 3.5a0, then uninstalled it again, and the py.exe launcher has
gone.
Either the 3.5 installer should notice that py.exe is already present and
remember *not* to uninstall
Paul Moore added the comment:
In this case as I said, no previous 3.50a1 installed. and I was doing an "all
users" install (which prompted me for elevation, and I said OK)
--
___
Python tracker
<http://bugs.python.o
New submission from Paul Moore:
I just tried to install the 64-bit "full installer" version, for
all users with the default options. This is on a PC that hasn't had
3.5 installed before, and doesn't have Visual Studio 2015 installed.
When it got to the step "precompilin
Changes by Paul Moore :
--
nosy: -pmoore
___
Python tracker
<http://bugs.python.org/issue20233>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
New patch incorporating Berker's comments
--
Added file: http://bugs.python.org/file38389/pep-441.v5.patch
___
Python tracker
<http://bugs.python.org/is
Paul Moore added the comment:
There have been no further comments for a while now. Could this be committed by
someone?
--
___
Python tracker
<http://bugs.python.org/issue23
Paul Moore added the comment:
I'm -1 on this. The whole point of having a .pyz extension is so that you don't
need to use an extension that's for files containing text to hold binary data.
If you want to do this, use zipapp and specify no interpreter line, then add
the @pytho
Paul Moore added the comment:
Updated patch including (I hope!) all review comments so far.
--
Added file: http://bugs.python.org/file38258/pep-441.v4.patch
___
Python tracker
<http://bugs.python.org/issue23
Paul Moore added the comment:
The PEP has now been accepted, and as far as I am aware this patch is complete.
If anyone has any review comments, please speak up, otherwise I believe this is
ready to be committed, if some kind soul is willing
Paul Moore added the comment:
Serihy, thanks for the explanation. I was aware that my replies weren't getting
archived, good to know how to avoid that in future.
I've worked out what you mean over the directory entries now. It was easy
enough to fix - I just removed the is_file ch
Paul Moore added the comment:
Serhiy - I just got a notification from the review tool - I'd not used it
before and didn't know to check it. But I've read them now and corrected a
number of places based on your comments and added a few replies to the review.
Thanks
Paul Moore added the comment:
OK, here is an updated patch based on the python-dev discussions
--
Added file: http://bugs.python.org/file38249/pep-441.patch
___
Python tracker
<http://bugs.python.org/issue23
Paul Moore added the comment:
Sorry - typo. Try again...
--
Added file: http://bugs.python.org/file38250/pep-441.patch
___
Python tracker
<http://bugs.python.org/issue23
Changes by Paul Moore :
Removed file: http://bugs.python.org/file38249/pep-441.patch
___
Python tracker
<http://bugs.python.org/issue23491>
___
___
Python-bugs-list mailin
Paul Moore added the comment:
OK, thanks. I don't propose to go there with the initial implementation. If
it's a problem in practice, someone can raise a bug and we'll fix it then.
(I've never seen actual Python code in the wild t
Paul Moore added the comment:
If I understand Steve's comments, the mime type is used by Windows, so
application/zip lets Windows know that this filetype is fundamentally a zip
file (and so it'll offer to open it with your zip program if you right click,
stuff like that).
pxzw -
Paul Moore added the comment:
Following on from that, the code to make an archive executable is currently
os.chmod(new_archive, os.stat(new_archive).st_mode | stat.S_IEXEC)
Should I use "... | stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH"? If so, do I
need to protect that with
Paul Moore added the comment:
I don't follow (and I don't really want to do things this low level without a
compelling reason...)
--
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
Thanks, I'll fix for the next iteration of the patch.
--
___
Python tracker
<http://bugs.python.org/issue23491>
___
___
Pytho
Paul Moore added the comment:
> As an alternative, virtualenv could be changed to create a pyvenv.cfg file
> with the interpreter version like pyvenv does. Seems pretty simple and
> unproblematic to me and it might actually be useful to know the interpreter
> version without r
Paul Moore added the comment:
On 20 February 2015 at 16:31, Wolfgang Maier wrote:
>> The scope of this PEP is just to make the "py" command (with no explicit
>> version) use an active virtualenv before falling back to the default Python.
>> This is specifically t
Paul Moore added the comment:
Thanks. Updated patch with the new mime-type.
Looks like there's disk errors on that file with the CRC check. Lovely :-)
--
Added file: http://bugs.python.org/file38192/pep441.patch
___
Python tracker
Paul Moore added the comment:
Hmm, I didn't know that (although virtualenv-based environments don't have an
equivalent to pyvenv.cfg).
But there's some confusion here. This patch only affects command line usage
(running "py.exe" to start Python). I don't really
Paul Moore added the comment:
That's correct. The problem here is that it's not possible to know what version
of Python a virtualenv has (at least, not without running it, which isn't
appropriate in the launcher). So the only case it's possible to
Paul Moore added the comment:
Thanks for checking, Steve. I don't get an installer because of the checksum
error quoted, although I did get the component msi files.
As far as content type is concerned, I wasn't sure what effect it had so I just
copied what was there. I guess appli
New submission from Paul Moore:
This is the patch for PEP 441 (Zip Application Support).
Steve, could you check the installer changes, please? I haven't managed to get
a setup where I can test the installer, and I'm not aware of any WiX coding
tools, so I just edited the XML fil
Paul Moore added the comment:
Sorry, I should probably have added them to the patch in the first place :-)
--
___
Python tracker
<http://bugs.python.org/issue23
New submission from Paul Moore:
Implementation of PEP 486 (Make the Python Launcher aware of virtual
environments). Tested manually on my local PC - there aren't currently any
tests for the launcher that I can see (and I'm not entirely sure how I'd write
such a test) so the
Paul Moore added the comment:
Martin, thanks for the clarification. When I said "I don't use it much" what I
meant was that I've never had it enabled, and for all of the repositories I
use, not doing so has never been a problem (until now). In contrast, git's
a
Paul Moore added the comment:
Correction. Looks like if I enable the eol extension, then hg revert
importlib.h, then rebuild, the problem then goes away.
So basically you need the eol extension enabled *before* you update/clone your
checkout
Paul Moore added the comment:
No, enabling the eol extension didn't fix it :-(
--
___
Python tracker
<http://bugs.python.org/issue23461>
___
___
Python-bugs-l
Paul Moore added the comment:
I'm just about finished for the night but I'll try the eol extension tomorrow.
I don't really use it much, though, my practice is generally to make all my
tools use LF. I certainly didn't do anything that would change that file, so
something
Paul Moore added the comment:
Ah. It's 4K lines of everything changing. Looks like it might be an EOL issue.
The build seems to be changing it from LF line endings to CRLF line endings.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Paul Moore:
When building Python (cpython repository, tip revision on the default branch)
using Visual Studio 2015 (version downloaded 12/02/2015) I get a message in the
build:
C:\Work\Projects\cpython\PCbuild\_freeze_importlib.vcxproj(98,5): error :
importlib.h has been
Paul Moore added the comment:
Sorry, yes pip just installs into %APPDATA%\Python\Python35\Scripts with no
issues.
--
___
Python tracker
<http://bugs.python.org/issue23
Paul Moore added the comment:
Cool, I've just run the tests by manually patching a 3.5a0 install. No extra
failures, so things look fine. (Interestingly, before patching, test_site
"altered the execution environment" but afterwards it didn't - it just
succeeded. I don&
New submission from Paul Moore:
Patch to make the user scripts directory on Windows
%APPDATA%\Python\PythonXY\Scripts rather than %APPDATA%\Python\Scripts.
See the thread "PEP 370 - per-user scripts directory on Windows" (Feb 10 2015)
on python-dev for discussion, but essentially
Paul Moore added the comment:
There's a lot of politics around the mingw vs mingw64 situation, but in
practice I believe the various mingw64 builds are fine. So I see no reason not
to supply a correct 64-bit libpythonXY.a.
When the patch was made to include the libpythonXY.a file to th
New submission from Paul Moore:
When you install Python 3.4.2 32 bit and 64 bit on the same PC, in that order,
the second one you install shows a red error message on the install screen,
saying "This update will replace your existing Python 3.4 installation", and
proceeds to uninst
Paul Moore added the comment:
Wait, sorry I misread the discussion (long day here). If we can do this in pip
yes that would be better. It looks like we can detect when we're being run via
pythonw by checking if sys.stdout is None.
--
___
P
Paul Moore added the comment:
This looks reasonable to me.
--
___
Python tracker
<http://bugs.python.org/issue22730>
___
___
Python-bugs-list mailing list
Unsub
Paul Moore added the comment:
Not a bad idea. I would want the implementation to remain in the documentation
as well, as code that wants to be portable back to earlier versions of Python
will need it. But for code that targets Python 3.5+ only, having it available
"out of the box"
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
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:
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:
Doh. And I was even involved in the previous issue. Sorry for the noise.
--
___
Python tracker
<http://bugs.python.org/issue22
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
Changes by Paul Moore :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9055>
___
___
Python-bugs-list
Changes by Paul Moore :
--
nosy: -pmoore
___
Python tracker
<http://bugs.python.org/issue8576>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
401 - 500 of 677 matches
Mail list logo
