Steve Dower added the comment:
I think this is best written as:
* extend py.exe to handle PEP 514 properly
* write "PythonCore\dev36" (or equivalent - maybe "PythonDev\dev36"?) keys on
each build
That way you could use "py -dev36" to get your latest build fr
New submission from Steve Dower:
Currently (on Windows) we register a set of subcommands in order to display an
expanding list of versions of IDLE when users right-click a .py file.
With issue27469, a proper shell extension was added, which means we can now use
IContextMenu to implement the
Steve Dower added the comment:
Another idea: we can also provide extra ("extended") commands when the user
holds Shift and right-clicks a file. We could use this to add items to do "-r
file.py" with IDLE, which would run the file with IDLE and
Steve Dower added the comment:
I just created issue27603 for any work that goes into adapting the IDLE context
menu. Pretty good chance I'll get to look at it for 3.6.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
> having two places for launcher configuration, the registry and the ini file,
> seems like it would be confusing
My hope here is that the registry is "the place where all your Pythons are
registered" and py.ini is "the place where setting
New submission from Steve Dower:
Now PEP 514 is accepted, we need to set more information when installing Python
3.6.
--
assignee: steve.dower
components: Windows
messages: 271197
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue27610>
___
Steve Dower added the comment:
This is deliberate. You should "vendor" packages into the embedded distro by
copying them from an install into a regular one. Your application installer
should put the correct files onto the user's machine - don't rely on pip.
If that last
Steve Dower added the comment:
Also, the doc page at https://docs.python.org/3.5/using/windows.html describes
this in more detail. (Though it doesn't yet refer to the Nuget packages as
those are an experiment that I may or may not con
Steve Dower added the comment:
It's core Python, but it's specifically intended for producing redistributable
installers containing Python packages. This is not something that the embedded
distro is meant for, and it neatens things up to omit them.
There is very little informati
Steve Dower added the comment:
Can MinGW build against Modules/getpath.c? I'd rather just use the posix
implementation than scatter ifdefs throughout the non-posix one.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Worth checking if the headers in VC14 have the structure now, as it may
simplify the whole thing.
If not, I'd add a leading underscore to the name so nobody confuses it for
public API in the future.
--
___
P
Steve Dower added the comment:
I think the WDK is still separate from the Windows SDK, so probably best to
keep the custom definition with a comment specifying which file it came from
(so whoever diagnoses an obscure issue in the future can find it quickly).
With the comment, I'm fine
Steve Dower added the comment:
Just as a data point, the .NET Framework's latest version removes all of their
extra path processing and lets Win32 do the validation/normalization (that is,
they used to do what we're considering, but now match our behaviour).
https://blogs.msdn.mic
Steve Dower added the comment:
I suspect it will also need the /Q option, at least on the one with the
wildcard, otherwise there will be a prompt. Though I'm not entirely clear on
where this is run (nmake?) so maybe it's already suppressed.
The fact that I'm not familiar wit
Steve Dower added the comment:
Looks good to me.
Sorry for not getting back to this after I said I would. Every time I
remembered I didn't have the time available...
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
I'd also suggest that this is potentially exploitable (if the Python code
calling into ctypes is already vulnerable - I don't think you could reasonably
manufacture an exploit simply from this bug) and it should probably go into all
active security b
Steve Dower added the comment:
Yeah, it's more a loose end than a real concern. Helps make the case for
reintegrating current libffi builds, as IIRC they've had the fix for a long
time, but we don't have anyone willing to do the integration
Steve Dower added the comment:
See https://github.com/pypa/pip/issues/3055 for an example of this error.
(Also note that there is a path limit of ~32k with the prefix, and that using
it also disables a lot of standard path resolution algorithms, so simply adding
it everywhere does not fix
New submission from Steve Dower:
According to
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
we can opt-out of MAX_PATH limitations on a selection of functions on the
latest version of Windows 10. This will allow unprefixed paths (i.e. no "\\?\")
Steve Dower added the comment:
Issue #27731 will resolve this for the latest versions of Windows 10, but if we
want to support this for earlier versions of Windows here's the algorithm I'd
suggest:
* if len(path) < 260 - we're good, don't do anything
* get the last
Steve Dower added the comment:
I thought I'd tested GetFullPathNameW and seen the limit kick in at 260, but if
that's not actually the case (across all platforms we support) then yes, let's
use that.
When I reread the documentation yesterday it didn't guarantee the resul
Steve Dower added the comment:
I'm now actively working on this for 3.6.
I've attached my first pass at implementing an alternative raw IO stream that
uses the *ConsoleW APIs instead of the CRT. It works fine for basic print() and
input() (including handling redirection "proper
Steve Dower added the comment:
The current patch actually only affects the raw IO, so the concern would be one
of the wrappers trying to work in bytes when it should be dealing in
characters. This should be no different from reading a UTF16 file, so either
both work or both are broken.
The
Steve Dower added the comment:
I'm working on this as part of my fix for issue1602. Not yet sure how this will
come out - compatibility with GNU readline seems to be the biggest issue, as if
we want to keep that then we can't allow embedded '\0' in the encoded text
(i.e. U
Steve Dower added the comment:
I'm fairly happy with where my current patch is at (not posted right now - too
many different machines involved) and only one test is failing - test_cgi.
The problem seems to be that urllib.parse.unquote() takes an encoding parameter
to decode utf-8 en
Steve Dower added the comment:
For more info here, cgi.parse has code like this:
def parse(fp, ...):
if fp is None:
fp = sys.stdin
encoding = getattr(fp, 'encoding', 'latin-1')
# later on...
return urllib.parse.parse_qs(a_str, encoding=encoding, .
Steve Dower added the comment:
It's certainly very easy to add an icon for pyd files. The tricky part is
getting an icon we can redistribute - fairly sure one derived from a Windows
icon is not redistributable.
Let me see if I can get one of the designers at work to put something tog
Steve Dower added the comment:
Can't promise there'll be a rocket, but the launcher icon will certainly be
different from the source file icon.
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
Got an impressively quick response from one of our willing designers, who has
proposed the attached icons.
In order, they would be:
* pythonw.exe
* py.exe (for reference, this mimics the Run launcher icon in Win10)
* All .py
* python.exe
* All .pyc
* All .pyd
Steve Dower added the comment:
It's probably not worth doing pyw.exe - even distinguishing between python.exe
and pythonw.exe is only possible because we came up with that icon before the
alternative one for the launcher.
The style just imitates the icon in the Run dialog (the "
New submission from Steve Dower:
I've attached my first pass at a patch to change the file system encoding on
Windows to UTF-8 and remove use of the *A APIs.
It would be trivial to change the encoding from UTF-8 back to CP_ACP and change
the error mode if that's what we decide is b
Steve Dower added the comment:
Thanks for the regen. I don't think git format is the problem as most of my
patches are fine, it's probably because it was in a patch queue and so the
parent isn't actually a known commit. I haven't tested whether this works
without my other
Steve Dower added the comment:
No, the flag that we add to the binary is backwards compatible. Earlier
versions will just ignore it.
--
___
Python tracker
<http://bugs.python.org/issue27
Steve Dower added the comment:
By portable, do you mean not using an environment variable?
Command line parsing is potentially affected by this on Windows - I'd have to
look deeper - as command lines are provided as UTF-16. But we may not ever
expose them as bytes.
I don't even
Steve Dower added the comment:
Ah I see, if we end up sticking with MBCS and offering a switch to enable
UTF-8. In that case, we'll definitely ensure the flag is the same (but I'm
hopeful we will just make the reliable behavior on Windows the default, so it
wo
Steve Dower added the comment:
Platform module version 1.0.8 added support for Windows 8.1 and later. You
actually downgraded to 1.0.7, which is why you lost functionality.
--
resolution: -> not a bug
status: open -> closed
___
Python t
Steve Dower added the comment:
It certainly looks like more than we used to get...
Ideally we'd capture the output from the build process and only write it out if
the test failed. I'm not entirely sure why that isn't happening here. The
warnings themselves are harmless (y
Steve Dower added the comment:
> Will it apply to third-party C extensions loaded into Python?
Yes, anything running under the python.exe will get it for free.
(Non-standard entry points will need to add the flag themselves.)
--
___
Python trac
Steve Dower added the comment:
Where did you install Python from?
--
___
Python tracker
<http://bugs.python.org/issue27836>
___
___
Python-bugs-list mailin
Steve Dower added the comment:
Nothing in Python 2.7 depends on vcruntime140.dll, so you shouldn't be seeing
that error from there.
My guess is that you have an extension module that requires it, or possibly
your PATH or PYTHONPATH variables were mixed up.
It sounds like everythi
Changes by Steve Dower :
--
resolution: -> not a bug
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue27836>
___
___
Python-bugs-list
Steve Dower added the comment:
> (Steve)> Doing the work to clean up the warnings really has to come second,
> ultimately.
> Second to what?
Second to enabling all the warnings, which is where the thread started. I need
to break my nasty habit on here of not quoting posts, but
Steve Dower added the comment:
Does it only check built code? I thought it would statically analyze
everything? Is MS_WINDOWS code excluded, because that would explain why it
"misses" issues.
--
___
Python tracker
<https://bu
Steve Dower added the comment:
I don't entirely agree with the analysis or suggestions here, but I do intend
to change this for 3.6 so I'll assign myself. At the very least, we won't fall
back on totally relative paths - we'll make them absolute from th
New submission from Steve Dower:
The console window for pip that appears during setup prevents us from having a
truly silent install.
This patch uses the CAQuietExec task from WiX, extracted and checked in
directly (the binary blob is omitted from the patch), to run the pip
install/uninstall
Steve Dower added the comment:
An almost immediate update - this patch also makes COMPILEALL not pop up a
window.
--
Added file: https://bugs.python.org/file44258/installer_2.diff
___
Python tracker
<https://bugs.python.org/issue27
Steve Dower added the comment:
New patch attached (1602_2.patch - hopefully the review will work this time
too).
I discovered while researching for the PEP that a decent amount of code expects
to be able to write ASCII to sys.stdout.buffer (or sys.stdout.buffer.raw). As
my first patch
Steve Dower added the comment:
This becomes more of an issue since VC++ 2008 Express is no longer available
for download (unless you're an MSDN subscriber), though the compiler itself is
still available as part of
http://www.microsoft.com/en-us/download/details.aspx?id=3138 (for VC9)
Steve Dower added the comment:
('ignore extra arguments' meaning they could be returned from find_vcvarsall()
and nobody will notice. Though it doesn't bother me if the fallback is handled
at a higher level.)
--
___
Python
Steve Dower added the comment:
I've dug deeper into VC10 and things are even worse there - without VS
installed I don't think there's any way for distutils to work without
completely replacing query_vcvarsall() (or msvc9compiler, for that matter).
I'm willing to writ
Steve Dower added the comment:
>> This becomes more of an issue since VC++ 2008 Express is no longer available
>> for download (unless you're an MSDN subscriber)
>
> Here: http://www.microsoft.com/en-us/download/details.aspx?id=13276
That's just the service pack and
Steve Dower added the comment:
>> That's just the service pack and it won't install unless you already have VS
>> installed. There is no way (other than being an MSDN subscriber) to get VS
>> 2008 at this point - I've checked.
>
> There is, but you
Steve Dower added the comment:
I've added a patch that replaces query_vcvarsall() with an implementation that
does not try and use the batch file. Instead, the functionality of the batch
file (effectively, reading the base path from the registry and appending
constants) is reproduc
Steve Dower added the comment:
Adding patch for 2.7.
--
Added file: http://bugs.python.org/file29755/msvccompiler9_27.diff
___
Python tracker
<http://bugs.python.org/issue7
Steve Dower added the comment:
If you deselect pip from the feature list, do you have any more success?
--
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
Unless Martin knows what could be going wrong, I don't think that's too helpful.
Can you run the following command from an elevated command prompt and post the
log it creates:
msiexec /l*vx log.txt /i (path to
Steve Dower added the comment:
Hmm, I'm used to seeing far more detail in verbose logs than that (normally
they'd be a few hundred KB).
I'm sorry, I don't know how to diagnose this issue. Have you tried clearing
your internet cache and downloading it again? Maybe try the 3
Changes by Steve Dower :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue22645>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
I wonder whether the same thing occurs if you're not appending a new extension
each time? There could be some optimisation (from the dark old days of 8.3
filename) that compares "baseExcel" and ".bak" separately and assumes that the
name
New submission from Steve Dower:
I'd like to be able to run ensurepip in the 3.5 installer with pythonw.exe, to
avoid having the console window appear.
Unfortunately, pip requires a valid value for sys.__stdout__. This patch adds a
dummy value for __stdout__ that allows pip to be inst
New submission from Steve Dower:
The test_capi.test_forced_io_encoding test currently requires that newlines
match when checking the results. This apparently does not occur with VC10
builds, but does appear with newer versions of the compiler.
This patch normalises the line endings in the
New submission from Steve Dower:
The test_pass_pointer and test_int_pointer_arg tests are inconsistent between
32-bit and 64-bit builds because c_long is always 32 bits but the function
being called may return a 64-bit value (it's a pointer, so c_long may truncate
it).
I'd prefer
New submission from Steve Dower:
The ffi_prep_args function in libffi_msvc/ffi.c needs the attached patch to
handle 64-bit parameters with the correct padding.
Without this patch, garbage may appear in the top part of 64-bit arguments as
the values are not zeroed out by the memcpy.
I'
New submission from Steve Dower:
This patch decreases the stack depth limit for Windows debug builds to prevent
the recursion test from failing. (Apparently VC14 uses more stack space for
each frame than VC10, but the release build is unaffected.)
Not sure who the correct nosy for marshal is
Steve Dower added the comment:
virtualenv is definitely chattier - it prints out the path where the env will
be and when it is installing setuptools and pip.
That's all that's really needed here too, IMHO - just enough to let users know
that venv has heard them and is doing some
Steve Dower added the comment:
I think the only thing pip could do is to stop using print(), which is not a
reasonable request.
It may be reasonable to change pythonw to use dummy IO streams by default, but
that may cause programs to print() messages expecting the user to see them.
It's
Steve Dower added the comment:
The generated output is using os.linesep, but the result from
run_embedded_interpreter() is not.
I assume there's a difference (fix) in MSVCRT between VC10 and VC12 (maybe VC11
- didn't test) that causes '\n' to flow through Popen.co
Steve Dower added the comment:
That change sounds like it'll be enough, and I'd be surprised if the logging
module doesn't already handle the case with no streams.
(Aside: it'd be nice for ensurepip to have a log file parameter that can be
passed through.)
I'll ho
Steve Dower added the comment:
Not so keen on having separate folders for Python version, mostly because I
want to avoid having the current version in too many locations. I've settled on
patchlevel.h as the canonical source of the version number for my VC14 branch -
everything else s
Steve Dower added the comment:
Practically this is very easy to do, and I'm more than willing to author
detection into the new PCbuild files.
Having nasm mirrored on svn.python.org (or anywhere on a PSF host) would be
real nice though. I don't particularly like making the build syst
Steve Dower added the comment:
> Argh, you're making me page _testembed back into my brain. I try to avoid
> having to do that ;)
Hehe, sorry.
> My guess would be that VC10 is translating '\n' to '\r\n' in the
> printf() calls, and VC14 has stopped doing
Steve Dower added the comment:
I missed c_size_t somehow, but as eryksun says, it's not strictly the same
thing. Of course, my current patch isn't the same thing either as it only
supports 32-bit and 64-bit pointer sizes.
I could make a bigger change to use c_void_p and compare
Steve Dower added the comment:
Paths are processed by the Windows API. This processing includes (at least):
* resolve to current directory
* convert forward slashes to backslashes
* remove adjacent backslashes
* trim trailing dots and spaces from names
* resolve short path names
This
Steve Dower added the comment:
Sounds good to me. I thought about the shared repo approach, but I don't
understand fully how merging between 2.7, 3.4 and default works in that
scenario (simply because I've never tried it - maybe it
Steve Dower added the comment:
I think it's also in any extension that prints directly to the console without
going through the Python IO machinery.
I'll make the test change in default, since that's what the os.linesep is
trying to achieve anyway, and modify the porting not
Steve Dower added the comment:
The 3.4 installer is still maintained by Martin.
--
assignee: steve.dower ->
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issu
Changes by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
As near as I can tell, Py_Initialize() is causing the stdout mode to change
from O_TEXT to O_BINARY in _testembed.
Looking at the output in this test, you can see the first printf('\n') (after
'Use defaults') is correctly translated, but
Steve Dower added the comment:
The fix for this now uses module without initializing it, which could lead to a
crash if get_dotted_path() tries to raise an exception (it puts module into the
error string with %R). See Modules/_pickle.c#l1656 and Modules/_pickle.c#l1538.
I think the fix is to
Steve Dower added the comment:
(Looks like I was outsmarted by the tracker when trying to put line numbers in
my links... is there a way to do that?)
--
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
Patch looks good to me, but given this issue, #11835, #22733, and probably
more, should we be integrating from libffi (which apparently has fixes for some
of these) more often? I know nothing about how we move code between that and
ctypes.
--
nosy
Steve Dower added the comment:
Had a look at where libffi is at, and we're such a long way from them now that
I don't think we can easily merge (a.k.a. I don't want to be the one to do it
:) )
I want to run this patch through some builds with the right compilers, but then
I
Steve Dower added the comment:
Done. Thanks mattip!
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
Upstream as in libffi? I'm fairly sure they've fixed it already, but their
current code bears little relation to what we have, so it's not easy to tell
and I didn't look all that closely.
Who&#x
New submission from Steve Dower:
I've merged the changes from when ensurepip was added to Python 3 into msi.py
(and also fixed up the new externals dir location), but I'm no expert on this
script, so at least a second set of eyes would be appreciated. It seems to
build and
Steve Dower added the comment:
Issue #22827 was the ensurepip backport.
--
___
Python tracker
<http://bugs.python.org/issue22850>
___
___
Python-bugs-list mailin
Steve Dower added the comment:
Yes, I'll add Scripts into the PATH when that option is enabled too. I ignored
that from the changeset I merged from, forgetting that that's where pip.exe
will end up.
I'd rather not bundle the launcher with Python 2 right now (if ever). With the
Steve Dower added the comment:
It's done.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Steve Dower added the comment:
Fixed. (I was conveniently sitting waiting for other things to build...)
--
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
Looks like a few Windows only things were missed. Can you track them down and
get them into a patch? I'm out of time to do more right now.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
That should be the last fix for Windows - a bit of code that was copied into
the new file but not removed from the old one.
--
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
You may be right, I didn't think of looking in the include files. I assumed
that it was copied without being removed, rather than the copy itself being
accidental. Feel free to move it back.
--
___
Python tr
Steve Dower added the comment:
Nosying the other Windows guys - seems like the ctypes nosy list is inactive,
and this only affects MSVC.
--
nosy: +tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issue22
New submission from Steve Dower:
I've basically finished the core of the work to refresh the PCBuild project
files and support building with VS 2015, and I believe it's ready to merge in.
Though the title says VS 2015, builds will work fine with VS 2010 and VS 2013
(and probably VS
Changes by Steve Dower :
Added file: http://bugs.python.org/file37247/projects_full.diff
___
Python tracker
<http://bugs.python.org/issue22919>
___
___
Python-bugs-list m
Steve Dower added the comment:
Oh, one other thing I just thought of: the current release of nmake (in VS
2015) has a regression that will make TCL and TK fail to build, but I have a
workaround for their makefile. OpenSSL also had a problem with VC14 but their
fix isn't in the build we&#
Steve Dower added the comment:
Fixed and pushed a minor issue with debug builds - I wasn't setting the 'g'
suffix on the tcltk libs correctly.
--
___
Python tracker
<http://bugs.pyt
4501 - 4600 of 5794 matches
Mail list logo
