Steve Dower added the comment:
Ah, okay, so this is due to the embedded DLL in the installer that we extract
and use to validate the install path (if you select a path that already exists,
you get a prompt warning you).
I don't know why your %TEMP% directory was not read/write/execute
Steve Dower added the comment:
When you install for all users, the msvcr90.dll is also installed for all users
and should appear in your System32/SysWOW64 directory.
What sort of problems are you facing? Compiled DLLs/pyds that are loaded into a
running Python process should reuse the already
Steve Dower added the comment:
Nope - closed.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
Newer versions of Windows Installer (this looks like an XP issue...) will
preserve a copy of the original MSI in a safe place, so this problem should not
occur any more.
I vote to close.
--
___
Python tracker
<h
Steve Dower added the comment:
Should be fine. Both 2.7 and default have the full OpenSSL version in
pyproject.vsprops, so they'll only use the version they expect.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
The "just for me" option isn't really "just for me". I'll probably have a real
option in 3.5, though it may still require admin rights.
There's no reason sites like www.portableapps.com couldn't provide true
per-user
Steve Dower added the comment:
I think they've all been fixed anyway, but yeah, they're not going to be
relevant with my new installer.
--
___
Python tracker
<http://bugs.python.
Steve Dower added the comment:
We could add an afxres.h file alongside install.rc that includes the code
posted by Lorenz Aebi. That will avoid the auto-generation issue, though it may
be overwritten if VS does actually generate code for it.
(I had thought that file was generated on project
Steve Dower added the comment:
This is probably because the program items are advertised. I have 2.7 and 3.3
installed, and when I pin the 3.3 Idle it switches to the 2.7 one. I guess
there's a GUID somewhere that makes the two icons identical, but I don't know
where that woul
Steve Dower added the comment:
As much as I like the idea of using OS handles everywhere, the compatibility
issues are probably too significant, and you can't mix CRT methods with OS
methods because the CRT does its own buffering. Of course, you can open a file
with the Win32 AP
Steve Dower added the comment:
It fails for me on 3.4.0rc1 and 3.3.4:
PS D:\> $env:PYTHONPATH
D:\Python33_x64\Lib\site-packages\virtualenv_support\pip-1.5.2-py2.py3-none-any.whl
PS D:\> py32 -V
Python 3.2.3
PS D:\> py32 -c "import pip; print(pip.__file__)"
D:\Python33_x6
Steve Dower added the comment:
I found that using zipimporter('...whl').load_module(pip) directly works fine,
so you may be able to use that as a workaround. (Forgot to mention it in my
initial comment, but that's what prompted me to check against the ABC.)
I also backed out t
Steve Dower added the comment:
Oddly enough, this works with 3.3.4 as released:
>>> import sys, zipfile
>>> with zipfile.ZipFile('test.zip', 'w') as f:
... f.writestr('test/__init__.py', b'print("Success!")')
...
>>>
Steve Dower added the comment:
My patches (which I've backed away from now - between wheels and monkey
patching Distutils from a setup.py, there are enough workarounds) also handled
the fact that VS 2008 is no longer freely/officially available, and presumably
VS 2010 will eventually g
Steve Dower added the comment:
I would be in favour of having separate keys for 32-bit and 64-bit installs (in
addition to the current one, if dropping it completely is not an option). We
use the registry keys in PTVS (http://pytools.codeplex.com/) to detect
installed interpreters, so the
New submission from Steve Dower:
In Python 3.4rc3, calling PyGILState_Ensure() from a thread that was not
created by Python and without any calls to PyEval_InitThreads() will cause a
fatal exit:
Fatal Python error: take_gil: NULL tstate
I believe this was added in http://hg.python.org
Steve Dower added the comment:
Should have linked to #19576 as well, which is the issue associated with that
changeset.
--
___
Python tracker
<http://bugs.python.org/issue20
Steve Dower added the comment:
UAC is still required for the installer - unfortunately MSI just doesn't
support having a single package that can do both elevated and unelevated
installs. Still, you can install once per-user and then copy the PythonXY
folder onto another machine, which
New submission from Steve Dower:
For the embedded zip and nuget releases, I've omitted bdist_wininst. However, I
forgot to remove the reference to it from distutils.command.__init__.__all__,
and so setuptools will occasionally crash trying to import it.
This patch updates Tool
Steve Dower added the comment:
The full fix may also require updating setuptools, which I'm pursuing, but we
also should stop referring to a module that isn't there.
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
Do you see a "Repair" option when running the installer again?
If not, open Programs and Features and find Python there, double-click it and
select "Repair".
Otherwise, you should have a set of log files in your %TEMP% directory (sort by
dat
Steve Dower added the comment:
A convenient test is:
python.exe -c "import distutils.core; distutils.core.setup()" --help-comm
ands
Without the fix, it raises "distutils.errors.DistutilsModuleError: invalid
command 'bdist_wininst'".
But yes, unfortunate
Steve Dower added the comment:
Thanks.
For reference, the setuptools issue is
https://github.com/pypa/setuptools/issues/857
A setuptools install from source should be fixed by this change, though an
install from a wheel (which is now typical, unfortunately) requires a separate
fix. But
Steve Dower added the comment:
Oh wow, I've never seen anything like this before. It looks like it's really
confused about whether you've installed for all users or not.
I wish I knew how you got into this state, because I'd like to be able to
prevent it. I guess it'
Steve Dower added the comment:
I was hoping that Repair wouldn't be an option after doing that cleaning. Maybe
try uninstalling through Programs and Features, then run those commands again,
go into the places you installed it and delete the files, and then run a fresh
install.
If you
Steve Dower added the comment:
For something as low level as os.popen you should read bytes and decode them
manually with the correct encoding. If you use subprocess.Popen instead you can
specify encoding="utf-8" in the call (on 3.6).
Unfortunately, it's a very bad idea to rely
Steve Dower added the comment:
Unless the reporter comes back with more information, I'll assume it's not a
bug.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs
Changes by Steve Dower :
--
nosy: +brett.cannon, eric.snow, ncoghlan, twouters -steve.dower
___
Python tracker
<http://bugs.python.org/issue28816>
___
___
Pytho
Steve Dower added the comment:
Looking at those logs, it seems like we think the per-user packages are already
installed. When you go to do an all-users install, it "removes" the per-user
packages, but passes in the same options as it does for the all user packages.
Under the h
Steve Dower added the comment:
This works fine in Python 3, and also Python 2.7 *unless* you call .keys().
PS D:\> py -2.7
Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits"
Steve Dower added the comment:
Ah, I see what you mean. In this case, we could change how the
case-insensitivity is handled here, but it would only be applicable to 3.7. I'm
not opposed to changing the default behavior here, but it does kind of bring up
the mapping dict discussion again
Steve Dower added the comment:
Could you attach those three sets of logs? I'm running low on ideas and need
all the inspiration I can get :)
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
That's only the most recent set, and all it shows is that the per-user install
didn't help.
Do you have the earlier sets of install logs for the per-user install and
uninstall? I'd like to see why those didn't have t
Steve Dower added the comment:
I don't think we have anyone actively tracking SQLite right now, like we do for
OpenSSL.
All it really needs is someone to prepare and test the patch during the beta
period, and to be available in case more fixes are required. At this stage,
we're
New submission from Steve Dower:
Currently the installer bundles for 3.5 and later have an automatically
generated dependency provider key. This makes it difficult for other installers
to correctly depend on the bundle.
For example, Visual Studio 2017 has an option to install CPython 3.5, but
Steve Dower added the comment:
Sorry, I got caught up in work stuff yesterday and didn't get a chance to go
through these. I'll try and find time today.
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
> installed 3.4 afterwards
Did you mean 3.5 here? If you're going to change versions, I'd at least suggest
grabbing the 3.6 beta - it's *much* better than 3.4, and we've had very little
trouble with the most recent version (RC is
Steve Dower added the comment:
This looks like it was my fault - I said I'd commit the patches and then never
got back to it.
I've assigned the issue to me so it doesn't fall off my radar again (though if
someone else wants to do it first they're welcome to). But at this s
Steve Dower added the comment:
> looks like only way to specify console's codepage is with
`encoding=os.device_encoding(2)` which will have to be used for 99% of cases
That's true, but it only applies when the subprocess is using the same call
(GetConsoleCP) to determine what en
Steve Dower added the comment:
It works for me. Can you confirm your operating system, and add the full output
from running these commands:
>>> print sys.version
>>> from urllib2 import urlopen
>>> urlopen('http://www.google.co.uk')
Steve Dower added the comment:
This bloated into a couple of extra build/installer fixes, including *finally*
fixing the sys._mercurial bug (I hope). I can also now merge fairly cleanly
between 3.5 and 3.6 again, so I'm happy for a while :)
--
resolution: -> fixed
stage: nee
Steve Dower added the comment:
Since it's not crashing, it is different from this issue. You should open a new
bug.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Is this the fork of MinGW specially for Python? I didn't think it supported 3.5
yet, because of the different CRT.
Also, I can't easily tell right now, but if you're using the libpython35.a
that's included with the regular install, you migh
New submission from Steve Dower:
We just discovered an issue where CPython install can fail on Windows 8, 8.1
and Server 2012.
* do not install the recommended UCRT update
* install any other Windows Update that requires a reboot
* install the *latest* VC Redist and do not reboot
* install
Steve Dower added the comment:
It's not intentional, but we clearly haven't done anything to prevent it.
Arguably this finder should be omitted when you run in isolated mode, and I'm
on the fence about deprecating it entirely. Adding the importlib experts in
case they have opi
Steve Dower added the comment:
+Ned
Could we get a doc patch into 3.6 marking this class as deprecated? It appears
like the importlib docs are the only ones that refer to the class, and none of
the docs describe the functionality or indicate that it is enabled by default.
I could also pitch
Steve Dower added the comment:
Here's my proposed doc change for 3.6.0. Any concerns about wording? (The
change to remove the line from _bootstrap_external.py will be separate, for
ease of cherry-picking.)
diff --git a/Doc/library/importlib.rst b/Doc/library/importlib.rst
--- a/Doc/li
Changes by Steve Dower :
--
keywords: +patch
Added file: http://bugs.python.org/file45794/28896_doc.patch
___
Python tracker
<http://bugs.python.org/issue28
Steve Dower added the comment:
If you run the installer through the Programs and Features dialog to modify or
uninstall it should definitely find the current installation (as the
registration it looks for is the same registration that makes it appear in that
dialog). Because there are
Steve Dower added the comment:
If you go to the 3.6 version of that doc page and also read the section on
finding modules, you'll see that the presence of a "python._pth" file causes -S
(skip importing site) to be implied unless the ._pth file includes "import
site":
Steve Dower added the comment:
I assumed silence meant everyone was happy with the wording, so I extended it
to whatsnew and NEWS and pushed.
Ned - the changeset above should be good for you to cherrypick.
I'll leave this issue open to cover actually removing the finder from
sys.meta_pa
Steve Dower added the comment:
Ah, did you change the default install directory to be the same as your
previous install? Yeah, that's bad :) There's other registration information
that we look at, so we don't even try and look at the existing files.
However, if you didn't
Steve Dower added the comment:
I have a better fix for this issue in the attached patch. It doesn't require
any change to setuptools in order to avoid crashing when installing from sdist
(e.g. Cython).
As before, this only involves changing the nuget package and its build scripts,
so
Steve Dower added the comment:
MSVC automatically inlines it on Windows (and yes, it broke some of our
debugging support in Visual Studio, but we can fix it by setting the eval func).
IMHO, inlining is best left to profiling optimizers. If you notice a
regression, add a test case that drives
Steve Dower added the comment:
Is it easy to cherry pick a merge commit? This will go into 3.5 first, but I
can null merge and then clean commit it if that's easier?
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Thanks Ned, it's all yours.
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue28783>
___
Steve Dower added the comment:
Arpit, could you look in your %TEMP% directory for the Python logs when you
originally installed it? There may be some information in those about why the
update didn't install properly the first time, and I'd like to fix it.
You can just zip up all th
Changes by Steve Dower :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Facing issue while running Python 3.6.0rc1 windows x86-64 web
based installer
___
Python tracker
<http://bugs.python
Steve Dower added the comment:
I don't support you have a file named "ucrtbase.dll" in your downloads
directory? That would be a really simple explanation, and I'd know how to fix
it.
If not, I don't have enough information from the logs to guess what the problem
ma
Steve Dower added the comment:
And that commit removes WindowsRegistryFinder from sys.meta_path on startup (as
well as fixing regeneration of importlib when building on Windows).
It should *not* be cherry picked for 3.6.0.
--
resolution: -> fixed
stage: commit review -> re
Steve Dower added the comment:
I'd rather only take the change to _msvccompiler and not the ones that are
there for historical interest (a.k.a. backwards compatibility with people who
never expect internal implementation details to change).
If any tools break because they're using
Steve Dower added the comment:
Looks like I acknowledged the error in the patch and then didn't fix it when I
applied it.
The change needed here is what Mark describes above, plus recompiling the
executable stubs. Or alternatively, I can probably just edit out the bytes in
the existing
Steve Dower added the comment:
Thanks. 3.5.3 is definite, I've pinged the release manage on the original bug
to see about 3.6.0, but definitely 3.6.1.
Considering we've gone through all of 3.5 and 3.6 with very few people noticing
(and as far as I'm aware, completely able to fi
Changes by Steve Dower :
--
assignee: -> steve.dower
keywords: +3.4regression
versions: +Python 3.7
___
Python tracker
<http://bugs.python.org/issu
Steve Dower added the comment:
What about the file, ucrtbase.dll? Do you have another file by that name
somewhere?
--
___
Python tracker
<http://bugs.python.org/issue28
Steve Dower added the comment:
Fixed for 3.5.3, 3.6.1 and default.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
Fixed for 3.5.3, 3.6.1 and default against the original issue26071
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> bdist_wininst created binaries fail to start and find 32
Steve Dower added the comment:
At least define EvalFrameEx in a header as an inline func, rather than copying
the body.
VS expected to walk the native stack and locate the f parameter in EvalFrameEx.
Since the function gets inlined, it couldn't find the frame. I use the JIT hook
to inse
Steve Dower added the comment:
It looks like you have a partial install there, possibly from an earlier
version.
Do you see a "Python" entry in Programs and Features? If so, running a Repair
on that may help, or removing it.
If you don't see another entry there, installing Pyt
Steve Dower added the comment:
(For anyone who comes here later, those last two commands are specially crafted
for this situation based on the attached log files. You'll likely need
different commands for whatever your situation is.)
--
___
P
New submission from Steve Dower:
With issue19717, WindowsPath.resolve() now properly resolves the filename using
the Windows APIs.
However, this may cause parts of the path to be replaced with their full name
when provided as the 8.3 short name. The test was not updated for this:
Traceback
Steve Dower added the comment:
The current _3.patch builds on default without warning and the tests pass
(_2.patch is the one Ned tried).
Any objections to committing this into 3.7?
What about 3.6.1? As an additive and easy to detect API, I think it's suitable,
and I will certainly u
Steve Dower added the comment:
I've committed to 3.6.1 and 3.7, but I'm not convinced that the problem is
worth the risk of changing the behaviour in 2.7.14 and 3.5.3.
Considering we kept forgetting to commit this for so long and largely got away
with it, I assume there aren
Steve Dower added the comment:
I'm not familiar with any of the other proposed solutions - could you link to a
few?
One important factor is that you need to install the Python Launcher to get the
context menus (this is the default in 3.5 and later). Associating directly to
the P
Steve Dower added the comment:
Guessing the msiobj_close function in PC/_msi.c ought to be exposed.
Patches welcome.
--
keywords: +easy
priority: normal -> low
stage: -> needs patch
versions: +Python 3.6, Python 3.7
___
Python tracker
Steve Dower added the comment:
The Python launcher is the right app to select. Double-clicking .py files has
always run them with the interpreter, but you will also get the right-click
menu once they are associated with the launcher (this is what I meant by it
being the single integration
Steve Dower added the comment:
C:\Windows\py.exe (probably. If you changed from the default options it may be
elsewhere, but if you Open With on a .py file it should be there)
--
___
Python tracker
<http://bugs.python.org/issue29
Steve Dower added the comment:
> Steve, you could move the "Edit with IDLE" menu out of the Python.File ProgId
> to an entry defined in SystemFileAssociations.
I could, but I don't want to. I'd rather figure out adding an "Open With" entry
for IDLE.
T
Steve Dower added the comment:
Lib/posixpath.py needs a huge amount of work to behave correctly for either
bytes or Unicode paths. I don't know why Lib/ntpath.py is okay here, but the
code is different so I suspect it just happens to not need the same conversion.
Switching for each pla
Steve Dower added the comment:
I just ran into this because PyModule_AddFunctions() was added to the stable
ABI in 3.5, but was not added to python3.dll.
This is blatantly a compilation error. We _need_ python3.def and the stable ABI
to be in sync.
I've rerun the script against Pytho
Steve Dower added the comment:
But you definitely have idle installed, right? The commands earlier made an
assumption about your installation that could be wrong, so that would explain
it.
I'm still not entirely clear whether you've done these steps yet:
1. Right-click a .py file
Steve Dower added the comment:
Guess I should at least pose the question - Ned, would you consider the change
in my patch for 3.6.0? Only the one file is affected, and it only contributes
to one DLL that is (a) recommended, (b) not widely used and (c) very
incompatible with the included
Steve Dower added the comment:
It looks like PyCharm has taken over your shortcut:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\UserChoice
HashREG_SZ55jxudRhknE=
ProgIdREG_SZPyCharm2016.3
If you delete the entire "FileExts\.py
Steve Dower added the comment:
> would this change likely affect any third-party binaries already built for
> 3.6.0? On the other hand, if we have to have one, it would be better to have
> a compatibility break at 3.6.0 rather than at 3.6.1.
Assuming we only make additive chan
Steve Dower added the comment:
> ast.h and node.h are private headers.
You're right, these should be excluded (possibly from the release too?)
I've been playing with the script in a separate context and I think I've hit a
few issues (though I have made some modificatio
Steve Dower added the comment:
Good call.
I think I might actually replace the script with a build step that uses the C
preprocessor to get all the names, then a script to generate the file. If
someone who knows the POSIX build system can help out, we could generate a list
on each build for
Steve Dower added the comment:
You should have a set of log files in your %TEMP% directory. Could you zip them
up and attach to this issue? That should show whether the installer got
confused about something.
Note that if you install the launcher but not for all users (the other check
box on
Steve Dower added the comment:
Great suggestion. If someone is willing to contribute the work then we can
consider it for 3.7.
If you need this functionality sooner, either ctypes or colorama should allow
you to use it on existing releases.
--
type: behavior -> enhancement
versi
Steve Dower added the comment:
Oh, and it should go in the WinConsoleIO class, needs to be written in C, and
probably needs a short PEP explaining why it has to be on by default and can't
be turned on by programs that need it. I'm sure the discussion will lead to
other ideas as wel
Steve Dower added the comment:
Those changes all look good to me, though it's a shame we can't leave some of
those functions out altogether.
--
nosy: +steve.dower
___
Python tracker
<http://bugs.python.o
New submission from Steve Dower:
Windows Vista SP2 is out of support by the time that Python 3.7 releases (see
PEP 0537 and [1]), so we should do the following tasks:
* update the definition of Py_WINVER in PC/pyconfig.h to 0x0601
_WIN32_WINNT_WIN7
* remove any dynamic API imports that are
Changes by Steve Dower :
--
title: Update WINVER to Windows 7 -> Remove Windows Vista support
___
Python tracker
<http://bugs.python.org/issue29075>
___
___
Py
Steve Dower added the comment:
Those macros like PyCFunction_New actually need to become functions again,
since we need real exports to forward them to the right place. Converting
stable API functions to macros breaks the ABI, since modules compiled against
the old one can no longer link to
Steve Dower added the comment:
Attached a patch that integrates generation into the build of python3.dll.
There are also a couple of fixes for headers to retain functions/data that were
previously exported.
The patch includes an updated python3.def file, though I expect that will go
away and
Steve Dower added the comment:
We should break out of the "while True" loop in _WindowsFlavour.resolve when
joining with ".." doesn't result in a different path.
--
___
Python tracker
<http:
Changes by Steve Dower :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue29079>
___
___
Python-bugs-list mailing list
Unsubscrib
Steve Dower added the comment:
Can we add a #warn to the headers then? So people know that just defining
Py_LIMITED_API actually implies =0x0305 (or whatever value is appropriate)?
--
___
Python tracker
<http://bugs.python.org/issue29
Steve Dower added the comment:
Unfortunately, there's no way too remove defined names from the DLL during
Python 3 at all, except where the prototype was never provided. PyCFunction_New
has always been a macro, and PySys_SetDefaultEncoding looks to have been
removed before the AP
Steve Dower added the comment:
> Just defining Py_LIMITED_API actually implies =0x0302.
That's the intent, but if it were actually the case then this issue wouldn't
exist :)
On 3.5.3, building with Py_LIMITED_API=1 will include APIs that should only be
included when P
Changes by Steve Dower :
--
stage: -> needs patch
type: behavior -> compile error
versions: +Python 3.7
___
Python tracker
<http://bugs.python.org/i
4201 - 4300 of 5794 matches
Mail list logo
