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:
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
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:
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:
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:
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
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:
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:
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:
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:
Looks OK to me.
I assume the differences between the math and cmath code and tests is because
cmath uses Argument Clinic and math doesn't, and cmath uses unittest.main
whereas math adds the suites manually? As far as I can see, that's what&#
Paul Moore added the comment:
I'm still somewhat confused as to why we're looking at this in the context of
manually building an extension. It's *certainly* true that anyone attempting to
build a Python extension by hand (as per Matthew Barnett's instructions) should
be
Paul Moore added the comment:
Personally, I'm OK with the wording in the 3.5.0b2 docs, as far as basic
terminology and glossary-style information goes.
I think coroutines, async, and event loops are badly under-documented in the
broader context, though - there is very little in the
Paul Moore added the comment:
+1 from me on this. Are there any specific technical implications (in terms of
ease of interoperability, ability to use a different compiler to build Python,
or whatever)? Whether there are or not, I'm still in favour - I think it's a
good thing anyway
Paul Moore added the comment:
Cool. Easier distribution is good. Better compatibility with GPL requirements
(depending only on "system facilities") is probably helpful for the general
community, too.
Embedding in C++ built with a different version of the compiler is always going
t
Paul Moore added the comment:
On 30 June 2015 at 23:30, M.-A. Lemburg wrote:
> I don't remember the details of why this feature was added,
> but can imagine that it was supposed to enable installation
> of new importers via .pth files.
I don't know for certain if this
Paul Moore added the comment:
As noted, this behaviour is as documented, and is deliberately designed to
execute the shebang line as either an executable (which calc is) or one of a
specific set of "virtual" entries (which does not include /bin/env).
--
resolution: -&
Paul Moore added the comment:
This is standard Windows behaviour. Executables are always located first in the
directory where your program (in this case the Python executable) is running
from - even before searching PATH.
If you want to use a different Python, you should specify the full path
Paul Moore added the comment:
Now that "Add Python to PATH" is an option on the front screen of the installer
(not hidden behind the scary "customize" option) this can be closed.
I recall Steve suggesting there might be issues with the way a user install
results in the
Paul Moore added the comment:
> Maybe we can special-case pip uninstalling it from the site-packages folder?
> *Paul* - any thoughts?
Sorry, I've been following this thread but it's been moving pretty fast, so I'm
probably replying too late to be helpful now :-(
One alte
New submission from Paul Moore:
At the moment, building an application that embeds Python requires the user to
have a full install of Python on the build machine, to get access to the
include and library files.
Now that we provide an embeddable build of Python on Windows, would it be worth
Paul Moore added the comment:
Also, the Windows build process is documented in PCBuild/readme.txt - see
https://hg.python.org/cpython/file/tip/PCbuild/readme.txt
More generally the devguide documents how to build CPython -
https://docs.python.org/devguide/setup.html#compiling
New submission from Paul Moore:
I have had a user install of Python 3.5rc3 for some time on one of my PCs. It
also had plenty of other versions on there - 3.4, 3.3, 2.7 and 2.6. The 3.5rc3
install was a user install.
I have my Python 3.4 install set up on PATH, and I've configured py.i
Paul Moore added the comment:
It's a very personal choice, but I prefer the current icons. I'm -1 on this
change.
--
___
Python tracker
<http://bugs.python.o
Changes by Paul Moore :
--
nosy: -paul.moore
___
Python tracker
<http://bugs.python.org/issue25444>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Why is it too late to install a new importer to sys.path_hooks when zipimport
is installed? As far as I am aware, running the stdlib from a zipfile works
fine, which seems to be equivalent to your use case.
--
nosy: +paul.moore
Paul Moore added the comment:
Just to clarify, it's intended that you simply "python -m pip install --upgrade
pip setuptools" to get the latest version.
--
nosy: +paul.moore
___
Python tracker
<http://bugs.pyt
Changes by Paul Moore :
--
keywords: +easy
___
Python tracker
<http://bugs.python.org/issue26336>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Moore:
See the following test (in Python 3.5):
>>> u'a\nb£'.encode('utf-8').splitlines()
['a', 'b\xc2\xa3']
I encode a string in UTF-8, then use the (bytes) splitlines function on it. The
return value is a list of st
Paul Moore added the comment:
That's weird. I can confirm it's working for me on 3.5.1. I'll double check I
wan't in 2.7 when I'm back at my work PC, but I didn't *think* I was. But
regardless, there's clearly no bug
Paul Moore added the comment:
Sigh. I had installed Python 2.7 at some point, and py.exe picked it up by
default :-(
Isn't it about time that py.exe defaulted to the latest version installed, not
the latest version of Python 2?
--
___
P
Changes by Paul Moore :
--
nosy: -paul.moore
___
Python tracker
<http://bugs.python.org/issue24557>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Moore:
People often look towards collections.namedtuple when all they actually want is
"named attribute" access to a collection of values, without needing a tuple
subclass, or positional access. In these cases, types.SimpleNamespace may be a
better fit.
Paul Moore added the comment:
Thanks Victor. I'll sort this out this evening when I get to my PC with access
to the CPython repo.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Paul Moore :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Paul Moore added the comment:
Ah, thanks. I probably did the commit the wrong way round in that case, as I
committed to tip. How should I do the commit into 3.5? (I'm also somewhat
confused by the fact that hg describes the 3.5 branch as &quo
New submission from Paul Moore:
By default, the launcher tries to launch (the latest version of) Python 2 on
the user's machine. This can be altered with the configuration file, and if the
user doesn't have Python 2 installed Python 3 will be used. Now that we are at
Python 3.6,
Paul Moore added the comment:
Thanks Steve. I wasn't sure over versioning, which is why I decided to be
conservative. Also, it's probably not good to change the default behaviour on
people when they just install a patch rele
Paul Moore added the comment:
Because of the nature of the launcher, there's not much we can do about that
IMO. And there was no real objection to changing the default on the
python-ideas thread (at least for interactive use).
But I'll wait to see if Ned has anyth
Paul Moore added the comment:
Thanks Ned. Personally, I'm still inclined *not* to add this to 2.7/3.5. People
will get it when the install the 3.6 alphas, sure, but that seems to me to be a
relatively obvious consequence of installing an alpha that includes a component
that's us
Paul Moore added the comment:
Terry: Correct.
As 3.4 is in security fix mode, and 2.7 doesn't come with the launcher (which I
hadn't realised - thanks for pointing this out Zach!) the only real backport
candidate is 3.5, so I definitely don't think it's worth backpo
Paul Moore added the comment:
OK, no problem. Like you say, not a high priority.
--
___
Python tracker
<http://bugs.python.org/issue27064>
___
___
Python-bug
Changes by Paul Moore :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue27064>
___
___
Python-bugs-list
Paul Moore added the comment:
My instinct is that this should only go into 3.6. It's a remote possibility,
but someone could otherwise write code that uses REG_DWORD64 and say that it
"works on 3.5" because they tested on 3.5.x, only to have it fail on 3.5.1.
But if someone wit
Paul Moore added the comment:
I'm not sure I follow your comment. In Python 3.5,
>>> from winreg import REG_QWORD
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name 'REG_QWORD'
So exposing REG_QWORD from the winreg mod
Paul Moore added the comment:
Hmm, OK. So code that currently needs to access QWORD values and decodes the
bytes returned would be broken by this change. Equally it is possible (albeit
not ideal) to get the data out with the current behaviour.
I can't judge how likely it is that anyon
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:
Thanks, I'll fix for the next iteration of the patch.
--
___
Python tracker
<http://bugs.python.org/issue23491>
___
___
Pytho
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:
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:
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:
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
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:
Sorry - typo. Try again...
--
Added file: http://bugs.python.org/file38250/pep-441.patch
___
Python tracker
<http://bugs.python.org/issue23
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:
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:
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:
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:
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:
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:
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:
New patch incorporating Berker's comments
--
Added file: http://bugs.python.org/file38389/pep-441.v5.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Paul Moore :
--
nosy: -pmoore
___
Python tracker
<http://bugs.python.org/issue20233>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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:
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:
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:
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:
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
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:
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:
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:
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
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:
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
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:
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:
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:
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:
Cool, I'll look at sorting it out.
--
___
Python tracker
<http://bugs.python.org/issue23657>
___
___
Python-bugs-list m
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:
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
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:
LGTM, just one minor comment in review.
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue23681>
___
___
Pytho
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:
Cool, no problem.
--
___
Python tracker
<http://bugs.python.org/issue23700>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
> 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:
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:
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:
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:
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:
Sorry, SOE?
--
___
Python tracker
<http://bugs.python.org/issue22516>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
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
Changes by Paul Moore :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
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:
... 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:
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
501 - 600 of 677 matches
Mail list logo
