New submission from Paul Moore:
There appears to be a significant issue with importing from zip files on Python
3.3.4. I have tested this on Windows 7, 64-bit, using the MSI installer from
python.org.
To reproduce, download virtualenv and extract the
C:\Work\Scratch\virtualenv-pfm
Paul Moore added the comment:
This is still the case in the 3.4rc0 Windows installer. Could we get something
definite for 3.4 final? It may be too late for that to be anything other than
documenting that the command "pip" is not available, but given that most 3rd
party documents us
Paul Moore added the comment:
Apologies, cut & paste error.
3.3.2 32-bit:
PS 20:49 C:\Work\Scratch\virtualenv-pfm
>py -3.3-32 -c "import pip"
PS 20:49 C:\Work\Scratch\virtualenv-pfm
>py -3.3-32 -V
Python 3.3.2
3.4rc0 is not affected either:
PS 20:54 C:\Work\Scratch\virtua
Paul Moore added the comment:
I'm afraid I don't have things set up to do a Python build right now. I *might*
have time later, and if so I'll give it a try, but I can't promise. Also, I
haven't yet managed to show the issue on 3.4.0rc1, but that may be because my
ch
Paul Moore added the comment:
OK, I have a build of 3.4 that shows the bug. How do I revert
http://hg.python.org/cpython/rev/20b77ff040b6 ? hg backout -r 20b77ff040b6 says
"abort: cannot backout a merge changeset".
--
___
Python trac
Paul Moore added the comment:
I tried hg backout 2807a5f011e4. It gave errors in the form of dialog boxes
titled "Microsoft Visual Studio" saying "File '-nosplash' not found". I've no
idea where these came from and whether they matter, but I tried clicking OK
Paul Moore added the comment:
Note - we're going to have to work around this bug in Virtualenv (even if it's
just in code specific to 3.3.4) so a workaround for 3.3.4 and an explanation of
what's going wrong would be useful, a
Paul Moore added the comment:
Thanks for the workaround. I'm going to try to do some serious testing of all
this over the weekend, I'll let you know how it goes.
--
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
Georg - see http://bugs.python.org/issue20621#msg211209 for what I did. That
shows backing out did *not* fix the issue. But I did backout on the default
branch, and my backout may not have worked as I explained.
I just tried to do hg backout on the 3.3 branch and
Paul Moore added the comment:
OK, confirmed.
Backing out to just before revision 2807a5f011e4 the problem has disappeared.
Re-applying just 2807a5f011e4 causes the issue to appear again.
--
___
Python tracker
<http://bugs.python.org/issue20
Paul Moore added the comment:
OK, I can confirm that both the patches fix the issue when applied to the
relevant branches.
--
___
Python tracker
<http://bugs.python.org/issue20
Paul Moore added the comment:
Can anyone confirm if this is a Windows-only issue? I need to know whether I
should block Python 3.3.4 in virtualenv for everyone, or just for Windows.
I only have Windows I can test on.
--
___
Python tracker
<h
Paul Moore added the comment:
Will someone make sure this gets logged the way it needs to for Larry's 3.4rc2
cherrypick process? Ta.
--
___
Python tracker
<http://bugs.python.org/is
Paul Moore added the comment:
I have reports from virtualenv users that this is not happening on Linux, BTW.
Could it be platform-specific somehow? Have the Unix users here been able to
reproduce this?
As regards a unit test, presumably we could ship a preconstructed zipfile in
the test
Paul Moore added the comment:
Re unit tests. Doh. Of *course* there are tests for importing from zipfiles.
And I just ran them (on Windows) and they worked. So there's something more
complex going on here and I don't know how you test for it, sorry (short of by
trying an import fr
Paul Moore added the comment:
Should this be mentioned in the 3.3.5 changelog
(http://docs.python.org/3.3/whatsnew/changelog.html)?
--
___
Python tracker
<http://bugs.python.org/issue20
Paul Moore added the comment:
OK, fair enough (I agree that the Windows behaviour here is the root cause of
the problem). However, it *would* have been possible for the registry keys to
be HKEY_LOCAL_MACHINE\Software\Python\PythonCore\3.4-32 and
HKEY_LOCAL_MACHINE\Software\Python\PythonCore
Paul Moore added the comment:
Agreed, that is not necessary. Nor was Martin suggesting it as far as I can
tell, he was simply saying that it would be less disruptive in the broader
scheme of things than messing with the Python registry scheme to work around
the limitation that 32 and 64 bit
New submission from Paul Moore :
Windows 3.x buildbots are failing in test_tarfile.
The problem, as best I can diagnose it, appears to be a failure
somewhere in the tarfile module to close files on exceptions. The error
is "WindowsError: [Error 32] The process cannot access the file becau
Paul Moore added the comment:
I can run a test on my buildbot - but I may not have a chance until
tomorrow. I'll do that and report back unless someone else reports
that they have managed to run a test before me.
--
___
Python tracker
Paul Moore added the comment:
I can confirm it fixes the issue, too.
--
___
Python tracker
<http://bugs.python.org/issue7341>
___
___
Python-bugs-list mailin
New submission from Paul Moore :
It looks like the "Control Panel\Desktop\dragfullwindows" registry entry
can have value 2 (it does on my buildbot!) The distutils test
"test_msvc9compiler" assumes that only values 0 and 1 are valid.
The following patch (against trunk) fixes
New submission from Paul Moore :
There is no way to determine the list of classes for which issubclass(C,
x) is true. The MRO of the class is fine for normal inheritance, but for
ABCs it is possible to register classes which don't inherit from the
ABC, so that you have a situation
Paul Moore added the comment:
I raised issue 5405. Armin Roachner commented over there that it's not
even possible in principle to enumerate the ABCs a class implements
because ABCs can do semantic checks (e.g., checking for the existence of
a special method).
So documenting the limitati
Changes by Paul Moore :
___
Python tracker
<http://bugs.python.org/issue5135>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/
Paul Moore added the comment:
I raised issue 5405. Armin Ronacher commented over there that it's not
even possible in principle to enumerate the ABCs a class implements
because ABCs can do semantic checks (e.g., checking for the existence of
a special method).
So documenting the limitati
Paul Moore added the comment:
Good point! So a documentation patch, to the effect that there is no way
of determining which ABCs a given class is an instance of, would be an
appropriate resolution, I guess.
___
Python tracker
<http://bugs.python.
Changes by Paul Moore :
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue2889>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
New submission from Paul Moore :
In revision 62197, Mon Apr 7 01:53:39 2008 UTC, Mark Hammond added code
to Lib/distutils/command/bdist_wininst.py which was intended to select
an architecture-specific installer executable.
In doing so, the code appears to have broken the ability to build
Paul Moore added the comment:
This sounds reasonable to me. I would like to see this patch applied.
Note - someone involved with the cygwin port should confirm that the
patch does indeed no longer cause issues for cygwin.
--
nosy: +pmoore
New submission from Paul Moore :
test_issue_8959_b fails when run from a service (in this case, from a
buildslave running as a service).
It appears to count the number of open windows, expecting a non-zero value. But
when run as a service, it looks like the return count is (correctly) zero
Paul Moore added the comment:
Martin's analysis (and the description of the commit he refers to) indicates
that the correct fix is Cuiseppe's suggestion to change the relative imports to
absolute:
from _multiprocessing import ...
as the previous code was only working because, as a
Paul Moore added the comment:
Here's a patch implementing the suggested change. test_multiprocessing passes.
I am just running the full test suite now.
--
keywords: +patch
Added file: http://bugs.python.org/file17849/mp.diff
___
Python tr
Paul Moore added the comment:
Full test suite also looks OK.
--
___
Python tracker
<http://bugs.python.org/issue9144>
___
___
Python-bugs-list mailing list
Unsub
Paul Moore added the comment:
I don't propose to raise a PEP myself. The issue with ABCs seems to me to be a
fundamental design issue, and I think it's better to leave raising any PEP, and
managing the subsequent discussion, to someone with a deeper understanding of,
and interest i
Paul Moore added the comment:
I don't think that they do, any more than for any .py script. (I assume you're
talking about in the .py script). Generated scripts on Unix can be whatever the
code wants, and on Windows I thought the idea of generated scripts had bee
Paul Moore added the comment:
Thanks for clarifying.
No, I don't agree. Barring fancy "if os.platform" games in setup.py,
scripts will be platform-independent Python code. From "Distributing
Python Modules" section 2.5, "Scripts are files containing Python
sou
Paul Moore added the comment:
I'm not sure what needs to be done to move this forward, but as it's a problem
with the test rather than with any actual code, could something be done to
avoid masking real issues? I agree with Thomas that in the absence of any other
solution, the a
Paul Moore added the comment:
I've had a look. I agree in principle with the change, and the code looks OK on
inspection, although I can't really test it. As it's only a change to one of
the scripts in tools/msi, this seems like a low-risk change to me, so
Paul Moore added the comment:
I thought that most of the users of this functionality had stopped doing so
(the only one I recall for certain was pywin32, and last time this came up, I
think someone said they had stopped).
If the functionality isn't used in any of the well-known modules
Paul Moore added the comment:
I'm OK for this to go in.
--
___
Python tracker
<http://bugs.python.org/issue28783>
___
___
Python-bugs-list mailing list
Paul Moore added the comment:
Does the git bash shell leave a readline DLL on the user's PATH? If so,
Python's readline support will kick in, and as a result Python will behave
differently.
--
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
Thanks for letting us know
--
___
Python tracker
<http://bugs.python.org/issue29093>
___
___
Python-bugs-list mailing list
Unsub
Paul Moore added the comment:
> Fully usable, portable
*and unsupported* - you apparently ignored that point from Steve's comment
> and working Python interpreter
That's (essentially) pure luck. I don't think I've ever seen any
suggestion that the /a flag for *any
Paul Moore added the comment:
I'm not sure I see why you'd want to run lib2to3 with the embedded distribution
anyway. Surely you'd do any 2to3 conversion in a normal development
installation, and then simply bundle the resulting converted scripts with your
application a
New submission from Paul Moore:
Trying to run a pyz file using the embedded distribution for 3.6.0, I get an
error "Could not import runpy module".
To reproduce, see below:
>type .\__main__.py
print('Hello, world')
>zip test.pyz __main__.py
adding: __main__.py (172
Paul Moore added the comment:
I just checked, and 3.6.0b1 (the only prerelease version I had available) has
the same problem. 3.5.2 works fine.
I thought I'd had similar code working during the beta cycle, but I can't
demonstrate that any more, so maybe my recollectio
Paul Moore added the comment:
Confirmed that it works with alpha 2, 3 and 4. But fails with beta 1 and the
release version.
--
___
Python tracker
<http://bugs.python.org/issue29
Paul Moore added the comment:
Sorry I should have thought of trying -v. The output (included below) doesn't
seem to offer many hints, though. runpy.pyc is in python36.zip, I checked that.
I'll see if I can find a machine without Python installed to test that case.
>.\python.exe
Paul Moore added the comment:
Nice! Thanks for finding this. I don't suppose there's any chance this would
qualify as a bugfix for 3.6.1? I've been holding off on working on
https://github.com/pfmoore/pylaunch until 3.6 because 3.5 doesn't handle being
in a subdirectory
Paul Moore added the comment:
> 2) you really want to have meaningful shebangs (ie, version-specific) in your
> scripts because, well, 2017 and the world is still split between py2 and py3,
This is the one I think is overspecifying. I don't see a really *good* reason
for not just
Paul Moore added the comment:
I agree, I don't particularly want versioned executables. I'm not sure I see
much point to even having versioned launchers - "py -2" and "py -3" seem fine
to me if needed.
The only use cases I can see are:
1. Use the Python execut
Paul Moore added the comment:
> - when inside a venv (almost always) go 'python' the old way, because 'py' is
> unreliable here, *unless* you manually check the shebang of your scripts
> before you execute them.
No. When inside a venv:
- If you want to use the
Paul Moore added the comment:
The embedded distribution is meant to be for just that - embedded applications.
I'm not quite sure what you mean by support it, or when you would write code
that needed to know it was being run from an embedded application.
Can you clarify precisely why you
Paul Moore added the comment:
With the embedded distribution, you should probably be calling the Python API
rather than running python.exe. And if you do it that way, you can set sys.path
via the API before calling user code.
Alternatively, you can set up a site.py within your copy of the
Paul Moore added the comment:
I'm still not clear what you're doing here - why does it matter where you have
the _pth file?
Could you explain how your application directory is laid out, and what is the
main executable for the application? I'm assuming it's a Windows ex
Paul Moore added the comment:
OK, well I certainly wouldn't bother supporting users trying to provide the
path to an embedded distribution of Python. That's not what the distribution is
for, and as the author of Bazel you'd be perfectly OK (IMO) to say you don't
support t
Paul Moore added the comment:
This sounds like a bug in winpython, not in Python itself. You need the
location of t1.py in your _pth file. See
https://docs.python.org/3.6/using/windows.html#finding-modules for details.
Python 3.5 didn't use the _pth file mechanism, which is why the beha
Paul Moore added the comment:
No (see the doc link I referenced) - paths are absolute, or relative to the
_pth file. So "." means "in the same place as the pth file".
I don't think there's a way with _pth files to get the "add the location of the
execu
Paul Moore added the comment:
I'm not sure about this, I've never seen __path__ used like this. Why can't you
just set sys.path?
sys.path.append(os.path.dirname(os.path.abspath(__file__)))
That's how scripts typically adjust their s
Paul Moore added the comment:
No more so than any other method of adding entries to sys.path (which is what
__path__ does for packages, I've just never seen it used for modules).
--
___
Python tracker
<http://bugs.python.org/is
Paul Moore added the comment:
It's probably worth also saying that maybe winpython shouldn't even be using
the _pth file feature. I don't know why it is, but the intended use case for
_pth files is embedded systems, so it's not clear how an alternative standalone
Python
Paul Moore added the comment:
>> an alternative standalone Python interpreter
>
> It's a convenient way to avoid having your standard library hijacked by
> registry keys installed by the regular interpreter.
Ah yes, that makes sense - it's maybe not the *right* way, bu
Paul Moore added the comment:
I have a vague recollection of once working on a (Windows) system that
mis-resolved localhost. But it was a long time ago, and I'm 100% OK with
calling such a system broken.
+1 on using localhost
--
___
Python tr
Paul Moore added the comment:
Thanks Tim.
To clarify, the only 2 places that pip calls ctypes is to get the user
application directory (and we've confirmed that doesn't error when called
direct from Python), and in the vendored colorama package (which we removed and
still got the
Paul Moore added the comment:
Confirmed I can reproduce the issue on Windows 7, with Python 2.7.12rc1. I
don't have C debugging capabilities on this PC, so that's as far as I can go
for now.
--
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
Tim, I just got the issue with the x64 installer from python.org
(https://www.python.org/ftp/python/2.7.12/python-2.7.12rc1.amd64.msi)
--
___
Python tracker
<http://bugs.python.org/issue27
Paul Moore added the comment:
The problem appears to be related to https (maybe openssl?) I just did the
following test:
>py -2
Python 2.7.12rc1 (v2.7.12rc1:13912cd1e7e8, Jun 12 2016, 05:57:31) [MSC v.1500
64 bit (AMD64)] on win32
Type "help", "copyright", "cr
Paul Moore added the comment:
Things I know that call CoInitialize - pywin32/pythoncom and comtypes. I assume
the proposal is to call CoInitializeEx in a way that won't break those?
I'm not sure I see how this would affect the user (i.e. Python code). Brett
mentions detecting
Paul Moore added the comment:
Hmm, this'll teach me to rely on my memory rather than checking :-)
It seems to me that core code that needs COM can use it by wrapping the code in
CoInitializeEx(sys.coinit_flags)...CoUninitialize(). That will either work fine
(I don't know where y
Paul Moore added the comment:
Strong -1 on anything that scans my locally-written scripts by default. There's
no reason or justification for that.
Maybe there's a point in having a way to submit an untrusted Python code
snippet for scanning, but why would that need to be a core s
Paul Moore added the comment:
OK, so a 3rd party module providing a "safe_exec" function would make a good
proof of concept, I assume. You could probably do that using comtypes or
pywin32.
I'm not going to try to say what is or isn't a security threat, that's no
Paul Moore added the comment:
>> I am puzzled as to why "use safe_exec rather than exec" isn't an option
> Because you're going to have a hard time convincing malware authors to use it.
:-) So the malicious payload is the whole python command, not just file.bin.
Paul Moore added the comment:
> This doesn't work when COM objects have to be kept around. In the AMSI case...
OK, so that's a limitation. Is there any *other* use case for keeping COM
objects (that are created by the core) around? If not, then like it or not,
this is a problem
Paul Moore added the comment:
I presume by "we" you mean "the core"? There's nothing to stop 3rd party code
using COM APIs.
The only downside to using COM in (user) Python code at the moment is the need
for a dependency on pywin32 (robust, mature, but a bi
Paul Moore added the comment:
Thanks for the explanation. Based on what's been said, I'd have no objections
to this, on a "you don't pay for what you don't use" basis - i.e., users who
don't enable AMSI should not pay any cost for its existence.
I'd be
Paul Moore added the comment:
This sounds like 2 related items (but I'm happy for them both to be under this
issue, I'm not suggesting we need 2 issues):
1. Allowing py -register to add PEP 514 metadata to the registry for the given
path.
2. Allowing py - to use PEP 514 met
Paul Moore added the comment:
On 23 July 2016 at 23:01, Eryk Sun wrote:
>> I assume you wouldn't expect to support shebang lines
>> like "#!python3.6r"?
>
> That's already supported in py.ini in the [commands] section, per PEP 397.
True, I'd forgot
Paul Moore added the comment:
LGTM. Maybe worth a documentation note - "Changed in 3.6 - added an exit
message"? But I'm OK with it as is if you don't think that's worth it.
--
nosy: +paul.moore
___
Python tracker
<http:
Changes by Paul Moore :
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue15867>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Moore:
The codecs module allows the user to register additional codecs, but does not
offer a means of getting a list of registered codecs.
This is important, for example, in a tool to re-encode files. It is reasonable
to expect that such a tool would offer a list of
Paul Moore added the comment:
@doerwalter In that case, I'd take the view that such a codec should simply not
return anything. The discovery mechanism can be limited to returning only
statically discoverable codec names (and it can be documented as such).
The original use case was to su
Paul Moore added the comment:
On 2 May 2013 16:35, Dmi Baranov wrote:
> Paul, result as iterable of CodecInfo objects is gives much more
> flexibility than the names of codecs (whats if you will have a few codecs
> with the same name in different SearchObjects?)
Works for me. My us
New submission from Paul Moore:
The Python launcher for windows should recognise a hashbang line of
#!/usr/bin/env python, and use the python executable found on PATH to run the
script. If no python executable is present on PATH the launcher should fall
back to the current behaviour (using
Paul Moore added the comment:
There is a patch for this (against the standalone pylauncher project) at
https://bitbucket.org/pmoore/pylauncher.
--
keywords: +patch
___
Python tracker
<http://bugs.python.org/issue17
Changes by Paul Moore :
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue12641>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
+1 for Oscar's proposed fix. It sounds like a sensible approach.
--
___
Python tracker
<http://bugs.python.org/issue12641>
___
___
Paul Moore added the comment:
On 23 May 2013 20:11, Roumen Petrov wrote:
> > Is this approach acceptable?
> It is not enough.
>
Support for compilers other than gcc (including cross-compilers) is a
separate issue, and one which is much less likely to
Paul Moore added the comment:
Not a bad idea. I would want the implementation to remain in the documentation
as well, as code that wants to be portable back to earlier versions of Python
will need it. But for code that targets Python 3.5+ only, having it available
"out of the box"
Paul Moore added the comment:
This looks reasonable to me.
--
___
Python tracker
<http://bugs.python.org/issue22730>
___
___
Python-bugs-list mailing list
Unsub
Paul Moore added the comment:
Wait, sorry I misread the discussion (long day here). If we can do this in pip
yes that would be better. It looks like we can detect when we're being run via
pythonw by checking if sys.stdout is None.
--
___
P
New submission from Paul Moore:
When you install Python 3.4.2 32 bit and 64 bit on the same PC, in that order,
the second one you install shows a red error message on the install screen,
saying "This update will replace your existing Python 3.4 installation", and
proceeds to uninst
Paul Moore added the comment:
There's a lot of politics around the mingw vs mingw64 situation, but in
practice I believe the various mingw64 builds are fine. So I see no reason not
to supply a correct 64-bit libpythonXY.a.
When the patch was made to include the libpythonXY.a file to th
New submission from Paul Moore:
Patch to make the user scripts directory on Windows
%APPDATA%\Python\PythonXY\Scripts rather than %APPDATA%\Python\Scripts.
See the thread "PEP 370 - per-user scripts directory on Windows" (Feb 10 2015)
on python-dev for discussion, but essentially
Paul Moore added the comment:
Cool, I've just run the tests by manually patching a 3.5a0 install. No extra
failures, so things look fine. (Interestingly, before patching, test_site
"altered the execution environment" but afterwards it didn't - it just
succeeded. I don&
Paul Moore added the comment:
Sorry, yes pip just installs into %APPDATA%\Python\Python35\Scripts with no
issues.
--
___
Python tracker
<http://bugs.python.org/issue23
New submission from Paul Moore:
When building Python (cpython repository, tip revision on the default branch)
using Visual Studio 2015 (version downloaded 12/02/2015) I get a message in the
build:
C:\Work\Projects\cpython\PCbuild\_freeze_importlib.vcxproj(98,5): error :
importlib.h has been
Paul Moore added the comment:
Ah. It's 4K lines of everything changing. Looks like it might be an EOL issue.
The build seems to be changing it from LF line endings to CRLF line endings.
--
___
Python tracker
<http://bugs.python.org/is
Paul Moore added the comment:
I'm just about finished for the night but I'll try the eol extension tomorrow.
I don't really use it much, though, my practice is generally to make all my
tools use LF. I certainly didn't do anything that would change that file, so
something
Paul Moore added the comment:
No, enabling the eol extension didn't fix it :-(
--
___
Python tracker
<http://bugs.python.org/issue23461>
___
___
Python-bugs-l
401 - 500 of 677 matches
Mail list logo
