Paul Moore <p.f.mo...@gmail.com> added the comment:
This is a pip issue, not a Python issue. It's a known issue in the current
version of pip, and should be fixed in the development version (via pull
request https://github.com/pypa/pip/pull/4486).
If you like, you can try the devel
Paul Moore <p.f.mo...@gmail.com> added the comment:
Good catch, thanks Serhiy!
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Paul Moore <p.f.mo...@gmail.com> added the comment:
Personally I don't see the value (in general, I don't see much use for the
whole custom command idea - making the launcher into a generalised shebang
processor was never really a core feature). But I'm not going to say no if
other
Paul Moore <p.f.mo...@gmail.com> added the comment:
@elguavas the problem is, no-one has proposed a patch. There's not likely to be
much movement on this until someone provides one.
--
___
Python tracker <rep...@bugs.python.or
Paul Moore <p.f.mo...@gmail.com> added the comment:
The docs for the curses module say "While curses is most widely used in the
Unix environment, versions are available for Windows, DOS, and possibly other
systems as well." This is the only mention of platform support I ca
Paul Moore <p.f.mo...@gmail.com> added the comment:
I'm not actually sure what the proposal here is. Are we suggesting that all
Python's means of terminating a process should use the same exit code?
Note that doing so would be a backward compatibility break, as os.kill() is
docu
Paul Moore <p.f.mo...@gmail.com> added the comment:
Also, one of the packages installed creates a file
configparser-3.5.0-py2.7-nspkg.pth
This has some very suspicious looking content:
import sys, types, os;has_mfs = sys.version_info > (3, 5);p =
os.path.join(sys._getframe(1)
Paul Moore <p.f.mo...@gmail.com> added the comment:
My feeling is still that it's an issue with things (i.e., imports) happening
before you adjust sys.path. But without seeing actual code that reproduces the
issue, there's no way of being sure. And if that is what's going on, it
wo
Paul Moore <p.f.mo...@gmail.com> added the comment:
> I did use `pip` to install packages as you'll see in the screenshot.
Sorry, I don't see any pip commands. Please could you include sample commands
inline as text, and not as screenshots, as attached files aren't accessible
fr
Paul Moore <p.f.mo...@gmail.com> added the comment:
The "backports" module you refer to as being in site-packages is not shipped
with the standard library, it's a 3rd party addon that presumably you installed
yourself. You'll need to let us know what you did to install
Change by Paul Moore <p.f.mo...@gmail.com>:
--
assignee: -> paul.moore
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https:/
Paul Moore <p.f.mo...@gmail.com> added the comment:
New changeset d87b105ca794addf92addb28293c92a7ef4141e1 by Paul Moore (Zhiming
Wang) in branch 'master':
bpo-31638: Add compression support to zipapp (GH-3819)
https://github.com/python/cpython/commit/d87b105ca794addf92addb28293c92a7ef
Paul Moore <p.f.mo...@gmail.com> added the comment:
Definitely. The reason it uses uncompressed files is simply an oversight on my
part - I hadn't realised the default for zipfile was uncompressed.
--
___
Python tracker <rep...@bugs.p
Paul Moore <p.f.mo...@gmail.com> added the comment:
Standard Windows behaviour, in my experience, is inherited permissions.
IMO, the current behaviour is correct - we default to an OS-managed secure
location for system wide installs, and a user-modifiable location for user
in
Paul Moore <p.f.mo...@gmail.com> added the comment:
I believe that's the case, although I'm somewhat surprised by the nature of the
error. I'm just checking diffs at the moment.
But VS 2015 is the officially supported compiler f
Paul Moore added the comment:
New changeset f1502d097c29b266a5748312ee2451a2d6ac0af6 by Paul Moore (Stefan
Grönke) in branch 'master':
bpo-31569: correct PCBuild/ case to PCbuild/ in build scripts and docs (GH-3711)
https://github.com/python/cpython/commit
Paul Moore added the comment:
OK, having re-read the PR, I'm fine with applying it as is, too.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Paul Moore added the comment:
I would strongly prefer the docs to be changed to match the implementation
rather than the other way round. However, I don't see the use case for this -
what case sensitive filesystem would anybody be building the Windows version of
Python on?
I'm -1
Paul Moore added the comment:
New changeset 0780bf7578dc4c9c3852dc5e869aba515a2c65b1 by Paul Moore in branch
'master':
bpo-31072: Rename the new filter argument for zipapp.create_archive. (#3049)
https://github.com/python/cpython/commit/0780bf7578dc4c9c3852dc5e869aba515a2c65b1
Paul Moore added the comment:
OK. There's been no further comments, and I think the differences with
PyZipFile's filterfunc are sufficient to warrant using a different name. I'm
going to go with "filter". It's short, and says wha
Paul Moore added the comment:
Sounds reasonable :-) I'm not going to be checking mails for a week or so, so
I'll revisit this once I get back.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Paul Moore added the comment:
Zipapp uses path objects throughout, so making the filter function take a path
object is consistent with that. I guess modifying PyZipFile to take either a
string or a path object would be possible.
As for the relative path, that's deliberate as I expect
Paul Moore added the comment:
I've created a new PR 3049 adding the fixes you suggested (and tightening up
the tests, as I noticed an untested aspect of the change while editing).
--
___
Python tracker <rep...@bugs.python.org>
Changes by Paul Moore <p.f.mo...@gmail.com>:
--
pull_requests: +3084
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31072>
___
_
Paul Moore added the comment:
Good point - I wasn't even aware of the filterfunc argument in PyZipFile. I'll
rename the argument.
I wasn't initially sure about a what's new entry. I'll add one - and thanks for
the reminder about versionadded
Paul Moore added the comment:
Thanks to Jeffrey Rackauckas for the implementation of this feature.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Paul Moore added the comment:
New changeset b811d664defed085d16951088afb579fb649c58d by Paul Moore (Jeffrey
Rackauckas) in branch 'master':
bpo-31072: Add filter to zipapp (#3021)
https://github.com/python/cpython/commit/b811d664defed085d16951088afb579fb649c58d
Paul Moore added the comment:
To be clear, Steve *is* our main Windows developer, and specifically the person
who developed the Windows installers we now use. They work perfectly for many
people, including myself, so there certainly isn't a general issue with them. I
myself routinely install
Paul Moore added the comment:
There are two problems with your code and bug report:
1. By using a single quoted string, some of the backslashes in the path are
being interpreted as starting a special character (specifically \t is
interpreted as a tab character). You should either double
Paul Moore added the comment:
No problem - glad it's all clear now.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31056>
___
___
Paul Moore added the comment:
I'm not Steve, but thanks for the compliment :-)
You're still running an embedded Python. There's a _python36.pth file next to
the executable, that's causing the behaviour you're seeing (and it's there by
design - it's what makes the embedded distribution behave
Paul Moore added the comment:
Hmm, never mind. This is expected behaviour because the embedded distribution
includes a ".pth" file which overrides the standard sys.path. For details, see
https://docs.python.org/3.6/using/windows.html#finding-modules and
https://docs.python.org
Paul Moore added the comment:
OK, so this is the first time (I believe) you have mentioned that you are using
the embedded distribution - which is not designed for general scripting use,
but very specifically for embedding Python in a custom application.
Can you reproduce with the standard
Paul Moore added the comment:
OK, so the problem is that no-one here (or as far as I can see on the SO
discussion, either) can reproduce your issue. So we have to assume that it's
something wrong with your environment, and not a Python issue.
If you can produce an example that allows us
Paul Moore added the comment:
Yes, they can be.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31072>
___
___
Python-bugs-list
Paul Moore added the comment:
I'd propose an extra argument to zipapp.create_archive, include_file=None (feel
free to bikeshed on the name). If the argument is not None, then it should be a
callable which will be called with a pathlib.Path object for each file that's
selected for inclusion
Paul Moore added the comment:
I've tested this on Python 3.6.1 and Python 3.6.2 on Windows 7, 64-bit, and it
works as expected. I don't see the problem here - do you have any unusual
environment settings or config?
--
___
Python tracker <
Paul Moore added the comment:
This is as documented - see
https://docs.python.org/3.6/library/os.path.html#os.path.join (" If a component
is an absolute path, all previous components are thrown away and joining
continues from the absolute path component"). In this ca
Paul Moore added the comment:
Note that even if you do get this working, you'll still need to run
pip from an elevated prompt every time you want to use it to install
new packages (or use --user).
--
___
Python tracker <rep...@bugs.python.org>
Paul Moore added the comment:
Presumably you overrode the default location of C:\Python27 in favour
of C:\Program Files?
I'm not sure we've ever supported installing Python 2.7 in "Program
Files", precisely because of the security constraints on that
directory (plus the fact that a
Paul Moore added the comment:
I suspect that the problem is somehow related to garbage collection - in your
failing example you don't keep any references to v or cb. I don't know what
references tkinter keeps internally, it may be that this is OK because the root
window is guaranteed to keep
Changes by Paul Moore <p.f.mo...@gmail.com>:
--
nosy: -paul.moore
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30574>
___
_
Paul Moore added the comment:
My bet is still on something like you compiling your code 32-bit and linking to
64-bit Python, or something like that.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Paul Moore added the comment:
Worked fine for me:
>cl .\pyc.c /I $env:LOCALAPPDATA\Programs\Python\Python36\include
>$env:LOCALAPPDATA\Programs\Python\Python36\libs\python36.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24213.1 for x64
Copyright (C) Microsoft Corporation
Paul Moore added the comment:
I'm a bit confused what you're asking for here.
Certainly if you embed Python, you can get crashes, just as with any other C
program. Pass an invalid pointer to a Python API, build your application and
the Python DLL with incompatible C runtimes, free memory you
Paul Moore added the comment:
I'm also not a fan of the -0 option. I'm OK with the ability to list available
interpreters, but there's nothing about -0 as an option that says to me that's
what it's for.
I'm not a huge fan of including the list in the standard help, as py -h already
generates
New submission from Paul Moore:
The documentation for the encoding of sys.stdin/out/err (see
https://docs.python.org/3.6/library/sys.html#sys.stdout) does not reflect the
change in Python 3.6 on Windows to use the console Unicode APIs, and hence
UTF-8 for the encoding.
--
assignee
Paul Moore added the comment:
Hmm, thinking a bit further, are you just suggesting registering the build as
-3.7? What if I were to build the 3.6 branch? Would that overwrite my "real"
3.6 registry entries?
As things stand, the launcher can only register two copies of Python for
Paul Moore added the comment:
I'd be wary of leaving out of date registry entries around. Maybe make it a
separate script (or part of build.bat but requiring a command line flag to
request it)?
Alternatively (or as well) we could have a cleanup command that removes
registry entries
Paul Moore added the comment:
The reasons for not adding Python to PATH by default are complex. We've tried
both ways and neither is 100% satisfactory.
The default install is a per-user install. If we added Python to PATH, then as
a user setting it would come *after* the system part of PATH
Paul Moore added the comment:
> Since we don't AFAIK have any possibility of mixed virtual environments
> ignoring SheBangs should meet the basic requirements of operating inside of a
> venv.
If you want a script to use the current environment, then #!/usr/bin/env python
does that
Paul Moore added the comment:
The behaviour you're describing for IE sounds like a bug to me. If you specify
a host that should bypass the proxy, then that's what should happen - it
shouldn't matter if you specify the host by IP address or by name.
I'm -1 on Python trying to match IE bugs
Paul Moore added the comment:
Also, you need to:
1. Ensure you are using characters that are available in the encoding that
sys.stdout uses - in Python prior to 3.6, this would be your Windows *console*
code page, and in 3.6+ would be UTF-8.
2. Declare the encoding of your source code if you
Paul Moore added the comment:
As you see from the banner, your Python 3.6 is 32-bit but your Python 2.7 is
64-bit.
I'd suggest you try 64-bit Python 3.6. This definitely looks like the SysWOW64
issue Eryk described.
--
___
Python tracker <
Paul Moore added the comment:
Please provide a script reproducing this issue, and precise details of your
Python version. It's extremely unlikely that the problem is as broad as you
describe, as otherwise we'd have lots of reports of issues. But we'll need a
more specific description
Changes by Paul Moore <p.f.mo...@gmail.com>:
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Paul Moore added the comment:
Also, this is a Python 2 only issue. The problem doesn't happen in Python 3.6
(at least in my quick experiment). I'm not 100% sure if this is because the
internal implementation of IO changed in 3.x, or if it's just because we're now
using a newer CRT which has
Paul Moore added the comment:
Thanks for that Steve. I had a recollection that there's a way of referencing
the PR itself as a branch within the main repo (I guess it must *be* a branch,
as how otherwise would github be able to do things like get Travis to build
it?) but I don't recall
Paul Moore added the comment:
OK, cool, thanks. I was sort of hoping for a way to just pull direct from
the PR (patches on Windows tend to be fiddly due to EOL issues), but I can go
with old-style :-)
Yes, with that patch applied it still works fine (I copied python3.dll and
python36.dll
Paul Moore added the comment:
Nick (or Steve) can you explain how I'd do that?
I have a git checkout of the 3.6 branch that I can build. But, how do I merge
in the changes from https://github.com/python/cpython/pull/575? The PR seems to
be against master, so I'm not sure how to apply
New submission from Paul Moore:
The 3.6.1rc1 build seems to have a spurious "^0" at the end of the version,
before the VCS ID - 3.6.1rc1^0):
>py -3.6
Python 3.6.1rc1 (v3.6.1rc1^0:e0fbe5feee4f9c00f09eb9659c2182183036261a, Mar 4
2017, 20:00:12) [MSC v.1900 64 bit (AMD
Paul Moore added the comment:
Confirmed that 3.6.1rc1 fixes the issue in my original use case.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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 tracker
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, but as a
pra
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 interpreter matches
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 <rep...@bugs.python.org>
<http://bugs.p
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 search path if needed
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
executed script
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 behaviour
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 that.
If you want
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 executable,
myapp.exe
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
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 need
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 interactive interpr
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 executable that'
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 sayin
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 very well. It'd
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 -v .\test.
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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 recollection is wrong
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 bytes sec
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 and the embedded
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* MSI installer (
Paul Moore added the comment:
Thanks for letting us know
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29093>
___
___
Pyth
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 <rep...@bugs.python.org>
Paul Moore added the comment:
I'm OK for this to go in.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28783>
___
___
Pyth
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, I'm
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 I'm OK
Paul Moore added the comment:
I agree that the docs are a little confusing on this. Having said that, though,
I'm not entirely sure the behaviour needs fixing. The scenario where there's a
problem is:
1. User has written a script that needs Python 3 and won't run with Python 2.
2. User does
Paul Moore added the comment:
1. I don't think searching . should be included - on Unix /usr/bin/env searches
PATH, and I believe we should do the same here.
2. The PATH search does happen (from my reading of the code) but it looks for a
"python3" command, which isn't availa
Paul Moore added the comment:
I can recreate this (based on the screenshots from #28366).
To reproduce, open IDLE. You get the console banner and prompt. Save that file
using File-Save. The close IDLE. Reopen it, do File-Open to open your saved
console session, then use the "Run" m
Paul Moore added the comment:
is_dir is a *method*. To find out if an entry is a directory, you need to call
it.
So you need
from os import DirEntry, scandir
def test_is_dir():
for item in os.scandir(TEST_DIR):
if item.is_dir():
# ^^ note change
Paul Moore added the comment:
OK, here's a first draft documentation patch. As it's purely a documentation
change, I guess it should go into the 3.5, 3.6 and trunk branches? For now it's
against trunk (it's not like that file has changed recently anyway), and I'll
sort out the merge dance
Paul Moore added the comment:
I'm still unsure whether this would be a good idea. On the plus side, it
provides (in conjunction with the "embedded" distribution) a really good way of
producing a standalone application on Windows. On the minus side there are some
limitations which m
Paul Moore added the comment:
(1) It starts an extra process (unless you're running the application from
cmd.exe) and (2) in some cases, the system won't recognise a cmd file as an
executable. For a simple example,
t.cmd:
@echo Hello from t
example.py:
from subprocess import run
run([&q
New submission from Paul Moore:
The zipapp module allows users to bundle their application as a single file
"executable". On Windows, the file is given a ".pyz" extension which is
associated with the Python launcher. However, this approach is not always
equivalent to a na
Paul Moore added the comment:
See https://docs.python.org/3/using/windows.html#embedded-distribution - "When
extracted, the embedded distribution is (almost) fully isolated from the user’s
system, including environment variables, system registry settings, and
installed pac
Paul Moore added the comment:
I'd prefer not to hard code __main__.py, as I'd quite like to be able to have a
number of copies of the executable, each running its own script. (I foresee
putting all my little Python utility scripts in a directory with a Python
installation and a set
Paul Moore added the comment:
You can actually handle this already, with a simple wrapper program (based on
the one in PC\WinMain.c):
/* Minimal main program -- everything is loaded from the library. */
#include "Python.h"
#define WIN32_LEAN_AND_MEAN
#include
int wmain()
{
Paul Moore added the comment:
In the light of Steve Dower's work to "un-deprecate" bytes paths, I agree this
should be added.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
201 - 300 of 675 matches
Mail list logo
