Steve Dower added the comment:
Basically through trusting the people who produce the builds.
You can also verify the hg changeset by looking at sys.version and matching it
to the tagged release. If there are any differences between the tagged commit
and the one used to build, there will be a
Steve Dower added the comment:
Creating a "dumb" item was discussed and rejected.
I don't see how passing the subkey is an issue if it works. The name of the
verb is considered public API surface, so we can't easily change it anyway.
What may be the issue is the use of
Steve Dower added the comment:
Does notepad handle clicking "edit" on a shortcut to a batch file? Maybe
subcommands don't have exactly the same semantics as regular verbs...
--
___
Python tracker
<http://bugs.pyt
Steve Dower added the comment:
I do need to contribute some PEP 101 updates at some point, since the Windows
build no longer resembles what is described there, but it's mostly about
configuration.
* Install x, y, z
* Obtain extra externals
* Install signing certificate
* Configure non-de
Steve Dower added the comment:
Having read your link [2] above (at least briefly), it seems the aim is to
compare hashes of builds from multiple people to verify that nobody maliciously
modified the binaries.
That isn't going to work for Windows because we cryptographically sign the
bin
Steve Dower added the comment:
if sys.version_info[:2] >= (3, 3):
# MSVC version is >= 9.0
Alternatively:
if sys.version_info[:2] >= (3, 5):
# MSVC version is >= 14.0, or
# _msvccompiler.MSVCCompiler does not have __version
or
if self.compiler.compiler_type == &q
Steve Dower added the comment:
The file is so small that a second copy is just as cheap - literally everything
is in the DLL. It could certainly be added to 3.6, and I'll probably get to it
eventually, but right now I'm still focu
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25091>
___
Steve Dower added the comment:
Well __version is determined by looking at sys.version to see what version was
used to build Python, so you aren't really getting the "actual" one, though in
practice it doesn't matter.
For Python 3.5 and later you could get different versio
Changes by Steve Dower :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issue25
Steve Dower added the comment:
Once you've established that MSVC is being used, you can infer the version from
the Python version, is what I meant by "it doesn't matter". The version
attribute on the compiler instance is never going to differ pre-3.5, and
post-3.5 i
Steve Dower added the comment:
After discussing it on the WiX mailing list, this definitely requires a change
to WiX.
Currently, as soon as you include any per-user packages in your bundle the
entire registration is forced to per-user regardless of whether or not they are
ever installed
Steve Dower added the comment:
WiX issue is http://wixtoolset.org/issues/4914/
--
___
Python tracker
<http://bugs.python.org/issue25166>
___
___
Python-bugs-list m
Steve Dower added the comment:
So basically what I said (-n becomes redundant) and a new option for logging
asserts to stderr? I don't really mind, but it seems like more of a
compatibility break.
--
___
Python tracker
<http://bugs.py
Steve Dower added the comment:
I was only going to disable them by default for regrtest. The only way users
will see them is when using the debug binaries or in their own extensions built
in debug mode. We just don't want them scaring users who have just built from
source and don't
Steve Dower added the comment:
There isn't one. MinGW doesn't support building with the UCRT yet, so you'll
need to link to a different version of the library and hope that it works (or
test/fix the extension).
--
___
Python
Changes by Steve Dower :
--
assignee: -> steve.dower
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Steve Dower added the comment:
Terry (nosied) made the request for the context menu in issue 23546, so if you
want it removed you'll need to convince him.
Personally I prefer the context menu, but I typically replace the default file
association with one that's better for me anyway
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25165>
___
Steve Dower added the comment:
It is a direct duplicate of multiple issues.
The assertion is coming from the CRT, because their definition of "undefined
behaviour" includes displaying an assert dialog in debug mode, and last time we
tried disabling them completely we upset people
Steve Dower added the comment:
This patch:
* defaults to no assert dialogs and no stderr output
* enables stderr output for assertions on "-vv" (or more)
* displays a deprecation message on "-n"
--
assignee: -> steve.dower
keywords: +patch
versions: +Pyth
Steve Dower added the comment:
I referred to the issues that had -n added in the first place many times while
adding the IPH handlers, but I don't have them handy now on my phone.
The rationale was that people who cause assertions in their C extensions should
see them and not have P
Steve Dower added the comment:
Ah, found it in the linked thread. I'll fix for 3.5.1.
--
___
Python tracker
<http://bugs.python.org/issue25316>
___
___
Pytho
Changes by Steve Dower :
--
assignee: -> steve.dower
components: +Windows
keywords: +3.5regression
nosy: +eric.araujo, paul.moore, tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issu
Steve Dower added the comment:
Do you have a full stack trace for that exception? I don't see anywhere that
should be able to raise WinError in _find_vcvarsall.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25316>
___
Steve Dower added the comment:
The Win32 API function linked by eryksun is the correct way to determine
whether to include the current directory in the search - the doc specifically
refers to matching cmd.exe's behaviour (searching ".;%PATH%" vs. just "%PATH%").
The
Steve Dower added the comment:
The new log looks like Win7 SP1 is needed.
I suspect in the original case there was some other update that was required as
well, but I don't know what it was. The prerequisites are the latest service
packs for Win7/WinS2K8 and earlier, and
Steve Dower added the comment:
Do you still get the same error from the Python installer?
--
___
Python tracker
<http://bugs.python.org/issue25157>
___
___
Pytho
Steve Dower added the comment:
Looks like you need to download the installer again (clear your internet cache
first to avoid getting the same corrupted file).
--
type: compile error ->
___
Python tracker
<http://bugs.python.org/issu
Steve Dower added the comment:
Shirshendu - any luck with eryksun's suggestions?
--
___
Python tracker
<http://bugs.python.org/issue25157>
___
___
Pytho
Changes by Steve Dower :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
Hopefully with the extra logging we'll be able to see if something is failing
at the point of detection. Any failure here (permissions in registry, etc.)
will cause the launcher to not be installed on upgrade (which might be the same
as removing it... I ne
New submission from Steve Dower:
Fixed in ee1ef5a97e8f
--
assignee: -> steve.dower
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Steve Dower added the comment:
The py launcher will prefer 2.7 because that's what was decided when it was
added. We're probably getting to a stage where we can revert that.
Unfortunately, there's no way we can reliably fix system configuration without
corrupting the users mac
Steve Dower added the comment:
They can find the 3.5 shortcut in their Start Menu (either by browsing or
searching for "IDLE") and then move that to their desktop.
Depending on operating system version, moving it could be:
* drag from the Start Menu to the desktop and drop it
* r
Changes by Steve Dower :
--
nosy: +steve.dower
___
Python tracker
<http://bugs.python.org/issue12939>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
Did that report come with any reason for SSE to be relevant, such as an error
message or log file?
Windows requires SSE these days, since Vista IIRC, so the problem is probably
someone on XP.
--
___
Python tracker
Steve Dower added the comment:
Since we officially support platforms that don't require SSE, I'll disable
those instructions for 3.5.1.
As eryksun points out, this doesn't affect 64-bit builds, which are the
standard for most performance critical uses anyway.
--
assign
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25361>
___
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25163>
___
Steve Dower added the comment:
Still need to validate the fix on WinXP, as I'm not 100% certain that enough UI
will appear to show the user the error, but we will now bail right at the start
and link to either help pages for installing updates (for Vista/7) or Python
3.4 (for pre-
Steve Dower added the comment:
Because of the way Open With works, we can't do this unless we start building
an EXE to launch IDLE (Windows automatically picks up most of the details from
the target executable, so it will show as "pythonw" if we do it without the
launcher
Steve Dower added the comment:
If they are compiled independently, they should have Py_BUILD_CORE set.
That flag is meant for the headers, which serve dual purposes, not the module
itself. *Any* C file that is part of core should expect that option to be set
for when it includes its headers
Steve Dower added the comment:
Between Victor's fix and #23919, is there anything left to do for this?
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
This should be fixed in numpy.distutils. The warning exists in
distutils.msvccompiler, which is deprecated and only remains in case people
were importing it directly (the only reference in the stdlib is the test suite
Steve Dower added the comment:
Issue #23970 added the new compiler class, but all that really changed is that
the module name is now distutils._msvccompiler. You *still* shouldn't access it
except through distutils.ccompiler.new_compiler(compiler='msvc'), which is how
it alway
Steve Dower added the comment:
Part of this will be the upgrade from RC, which will behave differently from
the next upgrade to 3.5.1. But I have just made some fixes in how upgrading the
launcher is handled, so there's a chance this is already fixed. But I'll test
this scenario to
Steve Dower added the comment:
I don't think it will be a significant breaking change at this stage to update
the default all-user install directory, since everyone *should* be resolving it
through the registry keys or overriding it on installation. Upgrading from
3.5.0 will not change t
Steve Dower added the comment:
I can confirm that this is fixed in an upcoming Windows update:
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for m
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25164>
___
Changes by Steve Dower :
--
assignee: -> steve.dower
___
Python tracker
<http://bugs.python.org/issue25450>
___
___
Python-bugs-list mailing list
Unsubscrib
Steve Dower added the comment:
Unfortunately it looks like MSI won't let you put an environment variable into
the shortcut, as it has to resolve it on install (see WkDir at
https://msdn.microsoft.com/en-us/library/aa371847(VS.85).aspx)
Trying some other ideas, but it looks like the
Steve Dower added the comment:
We can add more options to the start menu icon, even something like "--start-in
%userprofile%" should work there, as it really is just a blob of text (though I
need to test that). Accepting "--start-in ~" and os.path.expanduser() would
als
Steve Dower added the comment:
That's a good idea.
Can you grab the log files from %UserProfile%\AppData\Local\Temp (sort by date
- they'll all be grouped together) and upload to this issue?
Like Felipe, you may want to censor some usernames/paths. If you do, please let
me kn
Steve Dower added the comment:
I've fixed the shortcuts. Let me know if you add any extra command line options
to Idle for setting a more useful start directory and I can add those to the
shortcuts as well.
--
resolution: -> fixed
__
Changes by Steve Dower :
--
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25450>
___
___
Python-bugs-
Steve Dower added the comment:
So with the 3.5 launcher being installed all-users by default, the attached
patch is a good option.
I'm not able to build 3.4 entirely, but I made the modification to the MSI
directly and it works fine, so I intend to go ahead and apply it (with some
extra
Steve Dower added the comment:
Can you try installing
http://www.microsoft.com/en-us/download/details.aspx?id=48145 and then install
Python again?
That installer is installing the same update for your machine as Python 3.5
requires, so our installer should skip it once it is on
Steve Dower added the comment:
The check is already added and will be in 3.5.1.
Changes to the python.org website should be suggested on
https://github.com/python/pythondotorg (but I agree it could be more clear on
the main site - the rule that we only support the same versions of Windows
Steve Dower added the comment:
It sounds like something went wrong during a previous installation (probably
not Python 3.5) and your system is stuck in an "installing" state (hence system
restore being disabled and the install mutex being held).
Those two logs are a month apart but
Steve Dower added the comment:
I use /i, ADDLOCAL=ALL and ALLUSERS=1 with success all the time (/a does not do
a real install - avoid it unless you know you'll be deploying the reduced size
MSI to the rest of your network, and *especially* avoid it if you don't know
why you'd
Steve Dower added the comment:
Also, this is not a bug (and even if it was, wouldn't be fixed for 3.4), but
feel free to keep discussing how to do these installs.
--
resolution: -> not a bug
stage: test needed ->
status: open -> closed
Changes by Steve Dower :
--
assignee: -> steve.dower
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Steve Dower added the comment:
It does, but you need to identify the error code precisely and use that to
provide the parameters when obtaining the message. It's more about localization
than a general way of obtaining error text. Better off just using our own
message in this case (whi
Steve Dower added the comment:
For 3.6 I think it's fine, but people are almost certainly relying on the
current message on their system and changing it at all for any existing release
is unnecessary pain (3.5.1 *might* be okay, but only because it's so recent).
It would be nice to
Steve Dower added the comment:
Correction, *import* not found, and the only way to resolve it is to do a
second scan of sys.path for the sole purpose of diagnostics. Probably more
harmful than helpful.
--
___
Python tracker
<http://bugs.python.
Steve Dower added the comment:
Right now all of the tests fail on Windows by default (cp437 for me).
If I change the default IO encoding to utf-8 (hacked into pylifecycle.c, since
PYTHONIOENCODING is ignored by subprocesses using -E), the four "Misconfigured"
tests crash at the o
Steve Dower added the comment:
The tools for VS 2015 is a known issue. I let the team know before they
released it but it was too late. There'll be an update soon that should work.
For Python 3.2 and earlier use http://aka.ms/vcpython27 and setuptools 6 or
later.
The SDK 7.1 layout do
Steve Dower added the comment:
The thing about bogus assumptions is that Python should paper over those
anyway. I can guarantee there's production code out there with the same
assumptions.
How do we make this work? No idea in the context of the bytes/str filename
convention differ
Steve Dower added the comment:
I don't know that we can necessarily provide correct information for those
errors as it depends where they actually fail. If we're simply passing on an
error from the loader, then there's very little we can do.
We may be able to make an educated
Steve Dower added the comment:
I appreciate the enthusiasm, but be aware that at best this will show up in
Python 3.4.4 only, and the timeline for that is very short.
You would have a better chance if you were to make this a monkey-patch via
setuptools. See
https://bitbucket.org/pypa
Steve Dower added the comment:
Thanks. For 3.5 and later we automatically grab Lib/**/* (except *.py[co]),
with Lib/test/**/* split out into a separate install option.
I disliked the manual updating as much as everyone else did :)
--
___
Python
New submission from Steve Dower:
When launching the installer to upgrade from a Python 3.5.0 install to 3.5.1,
the path shown on the Install button is incorrect. Clicking the button installs
to the correct location.
This is a regression from 3.5.0 that will cause a lot of confusion. It ought
Steve Dower added the comment:
Fix attached:
* moves the UI update to the correct time (*after* we've detected the path)
* fixes a launcher detection issue I noticed
* removes a duplicated function
--
keywords: +patch
Added file: http://bugs.python.org/file41152/25715_1.
Steve Dower added the comment:
Launcher detection still isn't quite right - another patch coming.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Man, dealing with the launcher is hard. But I've got it about as good as I can:
* when installing 3.5.1 over 3.5.0, user has the option to update/not update
the launcher (no option to uninstall at that time)
* after installing 3.5.1, launcher can be adde
Steve Dower added the comment:
That patch looks good to me.
LOCALAPPDATA is set by the operating system, typically to
C:\Users\\AppData\Local (at least since Vista I think? Certainly
since Win7). While it's possible to customize it, people who know how to do
that won't be emailing
Steve Dower added the comment:
The proper fix is to remove any hint in the readme file that this will work.
Building 2.7 with VS 2015 will not work unless someone forks CPython and makes
the updates themselves.
--
___
Python tracker
<h
Steve Dower added the comment:
Not off the top of my head, but you only really need to look at my commits, and
looking for issues assigned to me is an easy way to find those.
Most of the issues are obvious once you start trying to build
Steve Dower added the comment:
Hard to tell, but you may just need to reboot. I'd also make sure you've
installed all Windows Updates that you need, as the one we're trying to install
should be in there (which means our installer doesn't have to do it).
The error code is
Steve Dower added the comment:
As you can see, I've now pushed to the main 3.5 branch, so feel free to
cherry-pick from there or give me the word and I'll graft it into the releasing
repo for you.
I also forward merged all the 3.5.1 NEWS into default. Not sure how that
normally ha
Steve Dower added the comment:
All registry values are blobs and it's up to the caller to decide how to read
it - the "types" are hints and are not binding.
I don't mind the default behavior being to trim at the first null, but it is a
lossy operation on our side and s
Steve Dower added the comment:
ExitProcess is a system API and exit is the C runtime API. The C runtime is
doing the buffering, so the system doesn't know about it and can't flush if you
terminate through that API. The exit function should, or we could explicitly
flush the bu
Steve Dower added the comment:
Considering we're building 2.7 and 3.5 tomorrow, ought we delay them long
enough to add a second RC with this change?
Looking at the issues that have been fixed, it doesn't seem like any are
critical.
--
Steve Dower added the comment:
It's worked fine on my Win10 machine (with all updates - they can't be turned
off easily on Win10...).
If you browse through the All Apps menu
(https://www.bing.com/search?q=windows+10+all+apps+menu) do you see Python
Steve Dower added the comment:
I don't want to do it without running it through the buildbots at least.
There's so much that can change just by rebuilding.
I'd love to say I have the time today to make the change and validate two
separate versions before producing the release
Steve Dower added the comment:
There's a separate issue in the 3.5.1 installer where the launcher is always
deselected on upgrade. I'm currently working on a fix to force it to always
install and we might push out a new 3.5.1 build later today.
If you go through Modify rather than R
Steve Dower added the comment:
Did you deselect everything else? That will remove it all.
--
___
Python tracker
<http://bugs.python.org/issue25089>
___
___
Pytho
Steve Dower added the comment:
The convention when modifying installations is to specify the end-state that
you're want, so unchecking something indicates that you want to remove it.
This could be made clearer, but it's probably a significant redesign of the UI.
At the least we cou
Steve Dower added the comment:
Needs a new release - up to Ben whether it's .12 or just a new .11. I can do
the build today or this weekend, but not in between.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Good to hear there's a workaround.
I seem to recall an issue in the past with some security policies that disallow
passing parameters to installers. This may be the cause here. When I get a
chance to sit at a computer I'll see if I can track
Steve Dower added the comment:
And for future reference, anyone who has Python in Program Files has
*explicitly* chosen to put it there. We always default to a location where the
current user can install packages as normal.
--
___
Python tracker
Steve Dower added the comment:
It hasn't been fixed for Windows yet.
--
___
Python tracker
<http://bugs.python.org/issue25798>
___
___
Python-bugs-list m
Steve Dower added the comment:
I was encountering this recently trying to set up a build machine for the
release, and it seems to be a build issue.
Martin is building the release and apparently has it working.
--
nosy: +loewis
___
Python tracker
Steve Dower added the comment:
There is: we can fall back on the cross compilers if the native ones are not
there.
Not a huge change, and safe enough.
--
___
Python tracker
<http://bugs.python.org/issue25
Steve Dower added the comment:
Doing the work to clean up the warnings really has to come second, ultimately.
The buildbot script also should be updated to pass that option.
--
___
Python tracker
<http://bugs.python.org/issue25
Steve Dower added the comment:
64-bit Python shouldn't have the -32 in sys.winver, so it isn't affected. (If
it does have the suffix, we have a second issue, but since it'd also be fixed
by removing the code Eryk quoted there's no ne
Steve Dower added the comment:
This is probably the registry key issue25824. That'll often show up as an
import error on site if you're loading python##.dll while outside of an install
directory. Without the key, it can't find its way to the stdlib.
Try renaming the registry k
Steve Dower added the comment:
The per-user installs collide without the name change, and since those are now
the default, it's important to have the change. The redirection you refer to
only occurs for HKLM and not HKCU.
The launcher was updated and tested to find all versions. If ther
5101 - 5200 of 5794 matches
Mail list logo
